The Inbox: KernelTests-cbc.277.mcz
Locked
 
|
A new version of KernelTests was added to project The Inbox:
http://source.squeak.org/inbox/KernelTests-cbc.277.mcz ==================== Summary ==================== Name: KernelTests-cbc.277 Author: cbc Time: 13 September 2014, 9:58:54.543 pm UUID: 035509c9-a60f-b44f-b55b-a17428783aa9 Ancestors: KernelTests-dtl.276 Added DateAndTimeArithmeticTest - to test adding things to DateAndTime instances. This includes things like: DateAndTime now + 3 days. Test convering adding various durations (like above) as well as addint strings, numbers, Timespans, Times, and DatAndTimes. Also tests subtracting the same. =============== Diff against KernelTests-dtl.276 =============== Item was added: + TestCase subclass: #DateAndTimeArithmeticTest + instanceVariableNames: '' + classVariableNames: '' + poolDictionaries: '' + category: 'KernelTests-Chronology'! Item was added: + ----- Method: DateAndTimeArithmeticTest>>testAddDateAndTime1 (in category 'testing') ----- + testAddDateAndTime1 + self assert: ((DateAndTime year: 2014 month: 1 day: 31) + (DateAndTime year: 2014 month: 3 day: 31)) = (DateAndTime year: 2014 month: 1 day: 31)! Item was added: + ----- Method: DateAndTimeArithmeticTest>>testAddDateAndTime2 (in category 'testing') ----- + testAddDateAndTime2 + self assert: ((DateAndTime year: 2014 month: 3 day: 31) + (DateAndTime year: 2014 month: 1 day: 31)) = (DateAndTime year: 2014 month: 3 day: 31)! Item was added: + ----- Method: DateAndTimeArithmeticTest>>testAddDays (in category 'testing') ----- + testAddDays + self assert: ((DateAndTime year: 2014 month: 1 day: 31) + 2 days) = (DateAndTime year: 2014 month: 2 day: 2)! Item was added: + ----- Method: DateAndTimeArithmeticTest>>testAddHours (in category 'testing') ----- + testAddHours + self assert: ((DateAndTime year: 2014 month: 1 day: 31) + 2 hours) = (DateAndTime year: 2014 month: 1 day: 31 hour: 2 minute: 0)! Item was added: + ----- Method: DateAndTimeArithmeticTest>>testAddIntegers (in category 'testing') ----- + testAddIntegers + self assert: ((DateAndTime year: 2014 month: 1 day: 31) + 2) = (DateAndTime year: 2014 month: 1 day: 31 hour: 0 minute: 0 second: 0 nanoSecond: 000000002 offset: DateAndTime localOffset)! Item was added: + ----- Method: DateAndTimeArithmeticTest>>testAddMinutes (in category 'testing') ----- + testAddMinutes + self assert: ((DateAndTime year: 2014 month: 1 day: 31) + 2 minutes) = (DateAndTime year: 2014 month: 1 day: 31 hour: 0 minute: 2)! Item was added: + ----- Method: DateAndTimeArithmeticTest>>testAddMonths1 (in category 'testing') ----- + testAddMonths1 + self assert: ((DateAndTime year: 2014 month: 1 day: 31) + 1 month) = (DateAndTime year: 2014 month: 2 day: 28)! Item was added: + ----- Method: DateAndTimeArithmeticTest>>testAddMonths2 (in category 'testing') ----- + testAddMonths2 + self assert: ((DateAndTime year: 2014 month: 1 day: 31) + 2 months) = (DateAndTime year: 2014 month: 3 day: 31)! Item was added: + ----- Method: DateAndTimeArithmeticTest>>testAddMonths4 (in category 'testing') ----- + testAddMonths4 + self assert: ((DateAndTime year: 2004 month: 1 day: 31) + 1 month) = (DateAndTime year: 2004 month: 2 day: 29)! Item was added: + ----- Method: DateAndTimeArithmeticTest>>testAddNanoSeconds (in category 'testing') ----- + testAddNanoSeconds + self assert: ((DateAndTime year: 2014 month: 1 day: 31) + 2 nanoSeconds) = (DateAndTime year: 2014 month: 1 day: 31 hour: 0 minute: 0 second: 0 nanoSecond: 000000002 offset: DateAndTime localOffset)! Item was added: + ----- Method: DateAndTimeArithmeticTest>>testAddSeconds (in category 'testing') ----- + testAddSeconds + self assert: ((DateAndTime year: 2014 month: 1 day: 31) + 2 seconds) = (DateAndTime year: 2014 month: 1 day: 31 hour: 0 minute: 0 second: 2)! Item was added: + ----- Method: DateAndTimeArithmeticTest>>testAddStrings (in category 'testing') ----- + testAddStrings + self assert: ((DateAndTime year: 2014 month: 1 day: 31) + '02:00:00:00') = (DateAndTime year: 2014 month: 2 day: 2)! Item was added: + ----- Method: DateAndTimeArithmeticTest>>testAddTime (in category 'testing') ----- + testAddTime + self assert: ((DateAndTime year: 2014 month: 1 day: 31) + ('02:00:00' asTime)) = (DateAndTime year: 2014 month: 1 day: 31 hour: 2 minute: 0)! Item was added: + ----- Method: DateAndTimeArithmeticTest>>testAddTimespan (in category 'testing') ----- + testAddTimespan + self assert: ((DateAndTime year: 2014 month: 1 day: 31) + + ((DateAndTime year: 2014 month: 1 day: 1) to: (DateAndTime year: 2014 month: 1 day: 3))) + = (DateAndTime year: 2014 month: 2 day: 2 hour: 0 minute: 0)! Item was added: + ----- Method: DateAndTimeArithmeticTest>>testAddWeeks (in category 'testing') ----- + testAddWeeks + self assert: ((DateAndTime year: 2014 month: 1 day: 31) + 2 weeks) = (DateAndTime year: 2014 month: 2 day: 14) + + ! Item was added: + ----- Method: DateAndTimeArithmeticTest>>testAddYears1 (in category 'testing') ----- + testAddYears1 + self assert: ((DateAndTime year: 2006 month: 1 day: 31) + 2 years) = (DateAndTime year: 2008 month: 1 day: 31)! Item was added: + ----- Method: DateAndTimeArithmeticTest>>testAddYears2 (in category 'testing') ----- + testAddYears2 + self assert: ((DateAndTime year: 2007 month: 1 day: 31) + 2 years) = (DateAndTime year: 2009 month: 1 day: 31)! Item was added: + ----- Method: DateAndTimeArithmeticTest>>testAddYears3 (in category 'testing') ----- + testAddYears3 + self assert: ((DateAndTime year: 2004 month: 2 day: 29) + 1 year) = (DateAndTime year: 2005 month: 2 day: 28)! Item was added: + ----- Method: DateAndTimeArithmeticTest>>testSubtractDateAndTime1 (in category 'testing') ----- + testSubtractDateAndTime1 + self assert: ((DateAndTime year: 2014 month: 3 day: 31) - (DateAndTime year: 2014 month: 1 day: 31)) = 59 days! Item was added: + ----- Method: DateAndTimeArithmeticTest>>testSubtractDateAndTime2 (in category 'testing') ----- + testSubtractDateAndTime2 + self assert: ((DateAndTime year: 2014 month: 1 day: 31) - (DateAndTime year: 2014 month: 3 day: 31)) = 59 days negated! Item was added: + ----- Method: DateAndTimeArithmeticTest>>testSubtractDays (in category 'testing') ----- + testSubtractDays + self assert: ((DateAndTime year: 2014 month: 3 day: 31) - 2 days) = (DateAndTime year: 2014 month: 3 day: 29)! Item was added: + ----- Method: DateAndTimeArithmeticTest>>testSubtractHours (in category 'testing') ----- + testSubtractHours + self assert: ((DateAndTime year: 2014 month: 3 day: 31) - 2 hours) = (DateAndTime year: 2014 month: 3 day: 30 hour: 22 minute: 0)! Item was added: + ----- Method: DateAndTimeArithmeticTest>>testSubtractIntegers (in category 'testing') ----- + testSubtractIntegers + self assert: ((DateAndTime year: 2014 month: 3 day: 31) - 2) = (DateAndTime year: 2014 month: 3 day: 30 hour: 23 minute: 59 second: 59 nanoSecond: 999999998 offset: DateAndTime localOffset)! Item was added: + ----- Method: DateAndTimeArithmeticTest>>testSubtractMinutes (in category 'testing') ----- + testSubtractMinutes + self assert: ((DateAndTime year: 2014 month: 3 day: 31) - 2 minutes) = (DateAndTime year: 2014 month: 3 day: 30 hour: 23 minute: 58)! Item was added: + ----- Method: DateAndTimeArithmeticTest>>testSubtractMonths1 (in category 'testing') ----- + testSubtractMonths1 + self assert: ((DateAndTime year: 2014 month: 3 day: 31) - 1 month) = (DateAndTime year: 2014 month: 2 day: 28)! Item was added: + ----- Method: DateAndTimeArithmeticTest>>testSubtractMonths2 (in category 'testing') ----- + testSubtractMonths2 + self assert: ((DateAndTime year: 2014 month: 3 day: 31) - 2 months) = (DateAndTime year: 2014 month: 1 day: 31)! Item was added: + ----- Method: DateAndTimeArithmeticTest>>testSubtractMonths3 (in category 'testing') ----- + testSubtractMonths3 + self assert: ((DateAndTime year: 2014 month: 3 day: 14) - 1 month) = (DateAndTime year: 2014 month: 2 day: 14)! Item was added: + ----- Method: DateAndTimeArithmeticTest>>testSubtractMonths4 (in category 'testing') ----- + testSubtractMonths4 + self assert: ((DateAndTime year: 2004 month: 3 day: 31) - 1 month) = (DateAndTime year: 2004 month: 2 day: 29)! Item was added: + ----- Method: DateAndTimeArithmeticTest>>testSubtractNanoSeconds (in category 'testing') ----- + testSubtractNanoSeconds + self assert: ((DateAndTime year: 2014 month: 3 day: 31) - 2 nanoSeconds) = (DateAndTime year: 2014 month: 3 day: 30 hour: 23 minute: 59 second: 59 nanoSecond: 999999998 offset: DateAndTime localOffset)! Item was added: + ----- Method: DateAndTimeArithmeticTest>>testSubtractSeconds (in category 'testing') ----- + testSubtractSeconds + self assert: ((DateAndTime year: 2014 month: 3 day: 31) - 2 seconds) = (DateAndTime year: 2014 month: 3 day: 30 hour: 23 minute: 59 second: 58)! Item was added: + ----- Method: DateAndTimeArithmeticTest>>testSubtractStrings (in category 'testing') ----- + testSubtractStrings + self assert: ((DateAndTime year: 2014 month: 1 day: 31) - '02:00:00:00') = (DateAndTime year: 2014 month: 3 day: 29)! Item was added: + ----- Method: DateAndTimeArithmeticTest>>testSubtractTime (in category 'testing') ----- + testSubtractTime + self assert: ((DateAndTime year: 2014 month: 3 day: 31) - ('02:00:00' asTime)) = (DateAndTime year: 2014 month: 3 day: 30 hour: 22 minute: 0)! Item was added: + ----- Method: DateAndTimeArithmeticTest>>testSubtractTimespan (in category 'testing') ----- + testSubtractTimespan + self assert: ((DateAndTime year: 2014 month: 3 day: 31) + - ((DateAndTime year: 2014 month: 1 day: 1) to: (DateAndTime year: 2014 month: 1 day: 3))) + = (DateAndTime year: 2014 month: 3 day: 29)! Item was added: + ----- Method: DateAndTimeArithmeticTest>>testSubtractWeeks (in category 'testing') ----- + testSubtractWeeks + self assert: ((DateAndTime year: 2014 month: 3 day: 31) - 2 weeks) = (DateAndTime year: 2014 month: 3 day: 17) + + ! Item was added: + ----- Method: DateAndTimeArithmeticTest>>testSubtractYears1 (in category 'testing') ----- + testSubtractYears1 + self assert: ((DateAndTime year: 2008 month: 1 day: 31) - 2 years) = (DateAndTime year: 2006 month: 1 day: 31)! Item was added: + ----- Method: DateAndTimeArithmeticTest>>testSubtractYears2 (in category 'testing') ----- + testSubtractYears2 + self assert: ((DateAndTime year: 2009 month: 1 day: 31) - 2 years) = (DateAndTime year: 2007 month: 1 day: 31)! Item was added: + ----- Method: DateAndTimeArithmeticTest>>testSubtractYears3 (in category 'testing') ----- + testSubtractYears3 + self assert: ((DateAndTime year: 2005 month: 2 day: 28) - 1 year) = (DateAndTime year: 2004 month: 2 day: 28)! |
|
|
This changes adds test for things like DateAndTime now + 2 days and DateAndTime now + 2 (the later of which adds two nanoSeconds - who would have guessed?) IT mostly tests to the current results of the most current Trunk, with a few exceptions: 1> Tests adding Months and Years, which currenty isn't supported (causes 13 errors), which are fixed in additional changes (covered in another email). If those changes are not acceptable, I can remove them.... 2> And error on TestSubtractString. Currently, it treats adding strings as if they were durations, but since String responds to #asDateAndTime, it treats them as if they were DateAndTime strings. I'd rather see them as durations in both cases, so expected to see it as a duration for subtracting, which causes an error. If this is wrong and the general expectation is that they should be DateAndTimes for subtracting and Durations for adding, I can change the test. (But it is really confusing and not clear!) 3> A failure in TestSubtractTime. Currently, Squeak treats adding a time as adding the time to the DateAndTime; but it treats subtracting a time as trying to figure out the difference between the DateAndTime and a a DateAndTime of the current date with the time portion set to the time. This is conterintuitive - does anyone expect this (or see any reason it would make sense)? I have setup the test to treat it as if we wanted to jut subtract whatever the time is from the DateAndTime. 4> A failure in TestSubtractTimespan. Currently, Squeak treats adding a Timespan to the DateAndTime as adding the span of time represented by Timespan to the DateAndTime. It treats subtracting the same as if you wanted the difference between the DateAndTime and the first (starting) dateAndTime of the TimeSpan. I would assume what is really wanted would be to subract the space of time from the DateAndTime instead. Does anyone dissagree with this desire? If these tests are acceptable, I can modify the behaviour to match the tests. If the current behaviour is correct, however, I can alter the tests to match that behaviour. What is the consensus? In either case, I would like to see these tests (possibly sanitized) added to Trunk, please. -cbc On Sat, Sep 13, 2014 at 10:00 PM, <[hidden email]> wrote: A new version of KernelTests was added to project The Inbox: |
Re: The Inbox: KernelTests-cbc.277.mcz
|
|
2014-09-14 7:30 GMT+02:00 Chris Cunningham <[hidden email]>:
Not me. nanoSeconds is totally arbitrary and just bound to the fact we currently (pretend to) have a nanoSecond clock. It was not true 10 years ago, and might not be true in 10 years, so my best guess would be the rise of an exception...
I don't understand this neither... If the purpose is to silently ignore user madness, then it makes sense, but I'd rather see an Exception educating me...
|
Re: The Inbox: KernelTests-cbc.277.mcz
|
|
In reply to this post by cbc
On Sun, Sep 14, 2014 at 12:30 AM, Chris Cunningham
<[hidden email]> wrote: > This changes adds test for things like > DateAndTime now + 2 days > and > DateAndTime now + 2 > (the later of which adds two nanoSeconds - who would have guessed?) Agree with Nico, this should be an exception. > IT mostly tests to the current results of the most current Trunk, with a few > exceptions: > 1> Tests adding Months and Years, which currenty isn't supported (causes 13 > errors), which are fixed in additional changes (covered in another email). > If those changes are not acceptable, I can remove them.... It seems like those enhancements would not cause any regressions. Is that true? If so, I'm liking them more and more. ;) > 2> And error on TestSubtractString. Currently, it treats adding strings as > if they were durations, but since String responds to #asDateAndTime, it > treats them as if they were DateAndTime strings. I'd rather see them as > durations in both cases, so expected to see it as a duration for > subtracting, which causes an error. If this is wrong and the general > expectation is that they should be DateAndTimes for subtracting and > Durations for adding, I can change the test. (But it is really confusing > and not clear!) Back in 2010, we abandoned the ability to compare a DateAndTime to a String. Allowing it caused a horrible performance penalty, even when not comparing to a String. I think we should do the same w.r.t. any other comparisons (e.g., #<) as well as the ariethmetic operators. Let the *user* of the DateAndTime send #asDateAndTime himself, rather than punish everyone else. Type conversions like that should be explicit anyway, not implicit. IMO, passing a String into DateAndTime>>#- or #+ should raise an error. DateAndTime>>#- should only accept EITHER another DateAndTime (which would answer a Duration) or a Duration (which would answer a DateAndTime) or a Timespan. > 3> A failure in TestSubtractTime. Currently, Squeak treats adding a time as > adding the time to the DateAndTime; but it treats subtracting a time as > trying to figure out the difference between the DateAndTime and a a > DateAndTime of the current date with the time portion set to the time. This > is conterintuitive - does anyone expect this (or see any reason it would > make sense)? I have setup the test to treat it as if we wanted to jut > subtract whatever the time is from the DateAndTime. For me, arithmetic between DateAndTime and Time does not make a lot of sense. Unless someone has a sensible use-case, I'm leaning toward it should be an error. > 4> A failure in TestSubtractTimespan. Currently, Squeak treats adding a > Timespan to the DateAndTime as adding the span of time represented by > Timespan to the DateAndTime. It treats subtracting the same as if you > wanted the difference between the DateAndTime and the first (starting) > dateAndTime of the TimeSpan. I would assume what is really wanted would be > to subract the space of time from the DateAndTime instead. Does anyone > dissagree with this desire? No. I mean, yes, I disagree. Timespans represent points-in-time of a particular duration (as you know). Just as adding two DateAndTime's together doesn't make a lot of sense, but *subtracting* them does, subtracting a TimeSpan from a DateAndTime makes sense but adding a TimeSpan was made to be "conveniently" sensible. Neither one is wrong, but there is a lot of code where the interplay between Dates and DateAndTime's might be expected to behave similarly as DateAndTime's with other DateAndTime's. For example: DateAndTime now - purchaseDate > 90 days ifTrue: [ ^ 'Warranty expired' ]. where purchaseDate is a Date. Its very reasonable to expect for the other Timespan types like DateAndTime now - ('3/1/2014' asMonth) to subtract the start of March, 2014 from #now. Changing or redefining that behavior to subtract the duration is not any more sensible than treating it as the start, but would break a lot of code. > If these tests are acceptable, I can modify the behaviour to match the > tests. If the current behaviour is correct, however, I can alter the tests > to match that behaviour. What is the consensus? Thanks for doing this work and for gathering consensus! > In either case, I would like to see these tests (possibly sanitized) added > to Trunk, please. Okay. |
|
|
On Mon, Sep 15, 2014 at 4:04 PM, Chris Muller <[hidden email]> wrote: On Sun, Sep 14, 2014 at 12:30 AM, Chris Cunningham ... > 4> A failure in TestSubtractTimespan. Currently, Squeak treats adding a Hi Chris, yes, this looks right. I had just looked at Timespan without looking at its subclasses, and tried building one like: Timespan starting: Date today duration: 3 days Building it this way isn't as obvious as, say, Date today (which is definitely something I'd like to compare against the start!). The subclass Schedule is kinda odd - we'll check the different between the date and the start of the schedule, but it still make sense IF it is documented that way. In line with the other suggestion - basically expecting errors for odd/unexpected combinations (like expecting the string to be a date/time for subtracting, and a time/duration string for addition), what do you think about adding Timespans or DateAndTimes to durations, such as: 1 hour + DateAndTime now ? It tries to just add the duration part of the second operand tot he duration - which is weird. So: Date today + Date today = Date today I would think these should raise errors as well. And thank YOU for sending me off on this path int he first place, and for the considered reply to what I'm trying to do. -cbc |
Re: The Inbox: KernelTests-cbc.277.mcz
|
|
On Thu, Sep 18, 2014 at 11:49 PM, Chris Cunningham
<[hidden email]> wrote: > On Mon, Sep 15, 2014 at 4:04 PM, Chris Muller <[hidden email]> wrote: >> >> On Sun, Sep 14, 2014 at 12:30 AM, Chris Cunningham >> <[hidden email]> wrote: >> > This changes adds test for things like >> > DateAndTime now + 2 days >> > and >> > DateAndTime now + 2 >> > (the later of which adds two nanoSeconds - who would have guessed?) > > ... >> >> > 4> A failure in TestSubtractTimespan. Currently, Squeak treats adding a >> > Timespan to the DateAndTime as adding the span of time represented by >> > Timespan to the DateAndTime. It treats subtracting the same as if you >> > wanted the difference between the DateAndTime and the first (starting) >> > dateAndTime of the TimeSpan. I would assume what is really wanted would >> > be >> > to subract the space of time from the DateAndTime instead. Does anyone >> > dissagree with this desire? >> >> No. I mean, yes, I disagree. Timespans represent points-in-time of a >> particular duration (as you know). Just as adding two DateAndTime's >> together doesn't make a lot of sense, but *subtracting* them does, >> subtracting a TimeSpan from a DateAndTime makes sense but adding a >> TimeSpan was made to be "conveniently" sensible. Neither one is >> wrong, but there is a lot of code where the interplay between Dates >> and DateAndTime's might be expected to behave similarly as >> DateAndTime's with other DateAndTime's. For example: >> >> DateAndTime now - purchaseDate > 90 days ifTrue: [ ^ 'Warranty expired' >> ]. >> >> where purchaseDate is a Date. Its very reasonable to expect for the >> other Timespan types like >> >> DateAndTime now - ('3/1/2014' asMonth) >> >> to subtract the start of March, 2014 from #now. Changing or >> redefining that behavior to subtract the duration is not any more >> sensible than treating it as the start, but would break a lot of code. >> > Hi Chris, yes, this looks right. I had just looked at Timespan without > looking at its subclasses, and tried building one like: > Timespan starting: Date today duration: 3 days > Building it this way isn't as obvious as, say, Date today (which is > definitely something I'd like to compare against the start!). > > The subclass Schedule is kinda odd - we'll check the different between the > date and the start of the schedule, but it still make sense IF it is > documented that way. > > In line with the other suggestion - basically expecting errors for > odd/unexpected combinations (like expecting the string to be a date/time for > subtracting, and a time/duration string for addition), what do you think > about adding Timespans or DateAndTimes to durations, such as: > 1 hour + DateAndTime now > ? It tries to just add the duration part of the second operand tot he > duration - which is weird. So: Hmmm... that's a tough one. And not because its not commutative, but simply that it MIGHT be useful to be able to add the current time to a Duration. Maybe we should determine the answer by asking ourselves, if someone wanted to add a duration to the current time of day, how would it be done? It looks like they would need to simply write: 1 hour + DateAndTime now asDuration which is more explicit. So, I think it would probably be fine to make "1 hour + DateAndTime now" produce an error, because implicit code is generally worse than explicit. > Date today + Date today = Date today > I would think these should raise errors as well. Hmm, yeah, again the user explicitly access the #duration, as in: Date today + Date today duration I'm slightly nervous that erroring on aTimespan + anotherTimespan would eliminate some kind of flexibility in some sophisticated app. But for everything else, it really seems like the code using the Chronology should be required to be more explicit.. I would say, lets go for it. Produce an error and let apps, if any, tell us why they think they would want to do that. :) > And thank YOU for sending me off on this path int he first place, and for > the considered reply to what I'm trying to do. No, thank YOU! :) We're all here because we enjoy analyzing and improving this stuff.. |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |