DateAndTimeLeapTest>>testAsSeconds is broken. The test passes incorrectly as a result of a false assertion:
self assert: aDateAndTime asSeconds = 3255514380.
Where aDateAndTime is specified in #setUp
aDateAndTime := (DateAndTime year: 2004 month: 2 day: 29 hour: 13 minute: 33 second: 0 offset: 2 hours).
This time is 2004-02-29T13:33:00+02:00, which in UTC is 2004-02-29T11:33:00+00:00.
The #asSeconds tests should test for elapsed seconds from the Smalltalk epoch until 2004-02-29T11:33:00+00:00. The correct number of seconds for this duration is 3255507180, not 3255514380 as asserted in the unit test.
By definition, #asSeconds is the seconds elapsed since the Smalltalk epoch (see its method comment). By common agreement, the Smalltalk epoch was defined relative to Greenwich Mean Time (UTC). If these two statements are both true, then the test is broken.
If there is no disagreement, I will fix the test and allow it to show the failure.
Dave
On Thu, Dec 1, 2016 at 4:51 AM, David T. Lewis lewis@mail.msen.com wrote:
DateAndTimeLeapTest>>testAsSeconds is broken. The test passes incorrectly as a result of a false assertion:
self assert: aDateAndTime asSeconds = 3255514380.Where aDateAndTime is specified in #setUp
aDateAndTime := (DateAndTime year: 2004 month: 2 day: 29 hour: 13minute: 33 second: 0 offset: 2 hours).
This time is 2004-02-29T13:33:00+02:00, which in UTC is 2004-02-29T11:33:00+00:00.
The #asSeconds tests should test for elapsed seconds from the Smalltalk epoch until 2004-02-29T11:33:00+00:00. The correct number of seconds for this duration is 3255507180, not 3255514380 as asserted in the unit test.
By definition, #asSeconds is the seconds elapsed since the Smalltalk epoch (see its method comment). By common agreement, the Smalltalk epoch was defined relative to Greenwich Mean Time (UTC). If these two statements are both true, then the test is broken.
If there is no disagreement, I will fix the test and allow it to show the failure.
Not necessarily disagreeing, but previously Squeak epoch was defined as local time. This is why "DateAndTime epoch" answers a local time.
This is basically because we had no time zone support at all, and no way to convert to UTC.
I agree basing it on UTC makes more sense, but I'm not sure how much code would need to change, and if some stored datetimes would be affected.
- Bert -
On Thu, Dec 01, 2016 at 11:07:45AM +0100, Bert Freudenberg wrote:
On Thu, Dec 1, 2016 at 4:51 AM, David T. Lewis lewis@mail.msen.com wrote:
DateAndTimeLeapTest>>testAsSeconds is broken. The test passes incorrectly as a result of a false assertion:
self assert: aDateAndTime asSeconds = 3255514380.Where aDateAndTime is specified in #setUp
aDateAndTime := (DateAndTime year: 2004 month: 2 day: 29 hour: 13minute: 33 second: 0 offset: 2 hours).
This time is 2004-02-29T13:33:00+02:00, which in UTC is 2004-02-29T11:33:00+00:00.
The #asSeconds tests should test for elapsed seconds from the Smalltalk epoch until 2004-02-29T11:33:00+00:00. The correct number of seconds for this duration is 3255507180, not 3255514380 as asserted in the unit test.
By definition, #asSeconds is the seconds elapsed since the Smalltalk epoch (see its method comment). By common agreement, the Smalltalk epoch was defined relative to Greenwich Mean Time (UTC). If these two statements are both true, then the test is broken.
If there is no disagreement, I will fix the test and allow it to show the failure.
Not necessarily disagreeing, but previously Squeak epoch was defined as local time. This is why "DateAndTime epoch" answers a local time.
This is basically because we had no time zone support at all, and no way to convert to UTC.
I agree basing it on UTC makes more sense, but I'm not sure how much code would need to change, and if some stored datetimes would be affected.
Here I am raising a different (but admittedly related) question. How many seconds elapsed between the Smalltalk epoch and the time 2004-02-29T13:33:00+02:00?
Dave
On Thu, Dec 1, 2016 at 2:29 PM, David T. Lewis lewis@mail.msen.com wrote:
On Thu, Dec 01, 2016 at 11:07:45AM +0100, Bert Freudenberg wrote:
Here I am raising a different (but admittedly related) question. How many
seconds elapsed between the Smalltalk epoch and the time 2004-02-29T13:33:00+02:00?
=> 3255507180 + DateAndTime localOffset asSeconds
My reasoning:
('1901-01-01T00:00:00+02:00' asDateAndTime - DateAndTime epoch) asSeconds = (0 + DateAndTime localOffset asSeconds - 7200)
and so
('2004-02-29T13:33:00+02:00' asDateAndTime - DateAndTime epoch) asSeconds = (3255514380 + DateAndTime localOffset asSeconds - 7200)
It can't be a constant but needs to take into account the local time zone. Because Smalltalk epoch is defined as local time, the difference to a fixed time necessarily involves the timezone offset.
- Bert -
On Thu, Dec 1, 2016 at 4:17 PM, Bert Freudenberg bert@freudenbergs.de wrote:
On Thu, Dec 1, 2016 at 2:29 PM, David T. Lewis lewis@mail.msen.com wrote:
On Thu, Dec 01, 2016 at 11:07:45AM +0100, Bert Freudenberg wrote:
Here I am raising a different (but admittedly related) question. How many
seconds elapsed between the Smalltalk epoch and the time 2004-02-29T13:33:00+02:00?
=> 3255507180 <(325)%20550-7180> + DateAndTime localOffset asSeconds
My reasoning:
('1901-01-01T00:00:00+02:00' asDateAndTime - DateAndTime epoch) asSeconds = (0 + DateAndTime localOffset asSeconds - 7200)
and so
('2004-02-29T13:33:00+02:00' asDateAndTime - DateAndTime epoch) asSeconds = (3255514380 <(325)%20551-4380> + DateAndTime localOffset asSeconds - 7200)
It can't be a constant but needs to take into account the local time zone. Because Smalltalk epoch is defined as local time, the difference to a fixed time necessarily involves the timezone offset.
Ah, but #asSeconds uses the epoch in the time zone of that DateAndTime instance, so it *is* a constant after all ... But it's not constant wrt your own local time zone.
Then again, maybe fromSeconds: and asSeconds should be symmetric. They're not, because asSeconds uses the instance's time zone, but fromSeconds: uses local time zone.
It's also quit possible I'm totally confused - I did not use independent resources but was just relying on Squeak.
- Bert -
On Thu, Dec 01, 2016 at 04:53:24PM +0100, Bert Freudenberg wrote:
On Thu, Dec 1, 2016 at 4:17 PM, Bert Freudenberg bert@freudenbergs.de wrote:
On Thu, Dec 1, 2016 at 2:29 PM, David T. Lewis lewis@mail.msen.com wrote:
On Thu, Dec 01, 2016 at 11:07:45AM +0100, Bert Freudenberg wrote:
Here I am raising a different (but admittedly related) question. How many
seconds elapsed between the Smalltalk epoch and the time 2004-02-29T13:33:00+02:00?
=> 3255507180 <(325)%20550-7180> + DateAndTime localOffset asSeconds
My reasoning:
('1901-01-01T00:00:00+02:00' asDateAndTime - DateAndTime epoch) asSeconds = (0 + DateAndTime localOffset asSeconds - 7200)
and so
('2004-02-29T13:33:00+02:00' asDateAndTime - DateAndTime epoch) asSeconds = (3255514380 <(325)%20551-4380> + DateAndTime localOffset asSeconds - 7200)
It can't be a constant but needs to take into account the local time zone. Because Smalltalk epoch is defined as local time, the difference to a fixed time necessarily involves the timezone offset.
Ah, but #asSeconds uses the epoch in the time zone of that DateAndTime instance, so it *is* a constant after all ... But it's not constant wrt your own local time zone.
Right. Neither of which makes any logical sense, because even if you wanted to define "epoch" relative to your local time zone, its value would change the next time you encounter a daylight savings time transition. And if you think that your "epoch" is relative to the offset of a DateAndTime instance that may or may not have been created in your local time zone, then that is another "epoch" entirely.
Furthermore, an instance of DateAndTime does not have a time zone, it has an offset, which is not the same thing at all. The offset for any given DateAndTime may or may not correspond to the time zone in which your Squeak image happens to be running. And the offset for any given time zone will vary as a function of time due to daylight savings time rules and other political factors (in the real world, not in Squeak).
Then again, maybe fromSeconds: and asSeconds should be symmetric. They're not, because asSeconds uses the instance's time zone, but fromSeconds: uses local time zone.
Right. At the very least it should be symmetric.
It's also quit possible I'm totally confused - I did not use independent resources but was just relying on Squeak.
Well yes, of course you are confused, you should be. I would have been very worried if you looked at this and thought that it made any sense ;-)
Dave
It's also quit possible I'm totally confused - I did not use independent resources but was just relying on Squeak.
Well yes, of course you are confused, you should be. I would have been very worried if you looked at this and thought that it made any sense ;-)
I haven't quite groked the issue myself just yet, but you definitely sound convinced there's a tangible issue, Dave. I agree that symmetry between those two converting methods sounds like it should be..
You said the number of seconds calculated since the "epoch" is wrong but mentioned it was merely in conflict with a comment. If we "fixed" the comment, would we still have a problem?
On Fri, 2 Dec 2016, Chris Muller wrote:
It's also quit possible I'm totally confused - I did not use independent resources but was just relying on Squeak.
Well yes, of course you are confused, you should be. I would have been very worried if you looked at this and thought that it made any sense ;-)
I haven't quite groked the issue myself just yet, but you definitely sound convinced there's a tangible issue, Dave. I agree that symmetry between those two converting methods sounds like it should be..
You said the number of seconds calculated since the "epoch" is wrong but mentioned it was merely in conflict with a comment. If we "fixed" the comment, would we still have a problem?
Do you know the answer to Dave's question "How many seconds elapsed between the Smalltalk epoch and the time 2004-02-29T13:33:00+02:00?"?
Levente
Why does it matter exactly how many seconds since the epoch?
On Fri, Dec 2, 2016 at 3:48 PM, Levente Uzonyi leves@caesar.elte.hu wrote:
On Fri, 2 Dec 2016, Chris Muller wrote:
It's also quit possible I'm totally confused - I did not use independent resources but was just relying on Squeak.
Well yes, of course you are confused, you should be. I would have been very worried if you looked at this and thought that it made any sense ;-)
I haven't quite groked the issue myself just yet, but you definitely sound convinced there's a tangible issue, Dave. I agree that symmetry between those two converting methods sounds like it should be..
You said the number of seconds calculated since the "epoch" is wrong but mentioned it was merely in conflict with a comment. If we "fixed" the comment, would we still have a problem?
Do you know the answer to Dave's question "How many seconds elapsed between the Smalltalk epoch and the time 2004-02-29T13:33:00+02:00?"?
Levente
If it doesn't matter, then what's the epoch good for?
Levente
On Sat, 3 Dec 2016, Chris Muller wrote:
Why does it matter exactly how many seconds since the epoch?
On Fri, Dec 2, 2016 at 3:48 PM, Levente Uzonyi leves@caesar.elte.hu wrote:
On Fri, 2 Dec 2016, Chris Muller wrote:
It's also quit possible I'm totally confused - I did not use independent resources but was just relying on Squeak.
Well yes, of course you are confused, you should be. I would have been very worried if you looked at this and thought that it made any sense ;-)
I haven't quite groked the issue myself just yet, but you definitely sound convinced there's a tangible issue, Dave. I agree that symmetry between those two converting methods sounds like it should be..
You said the number of seconds calculated since the "epoch" is wrong but mentioned it was merely in conflict with a comment. If we "fixed" the comment, would we still have a problem?
Do you know the answer to Dave's question "How many seconds elapsed between the Smalltalk epoch and the time 2004-02-29T13:33:00+02:00?"?
Levente
Do you know the answer to Dave's question "How many seconds elapsed between the Smalltalk epoch and the time 2004-02-29T13:33:00+02:00?"?
IOW, as long as this private, internal number is consistent for the callers, does it matter what the number is? Whether the internal "starting point" is midnight, 2am, 6am or 7:37:59am for that matter? The comment just says "1 January 1901" it does not specify a time, could we just clarify the exact time in the comment and then everything be fine?
Or is there some calculation or scenario for an application that is not consistent and correct due to this?
One issue appears to be that the #epoch is calculated relative to "self localOffset". So #epoch reports technically different times depending what one's #localOffset is.
|dt1 dt2| dt1:= '2004-02-29T13:33:00+02:00' asDateAndTime. dt2 := '2004-02-29T11:33:00+00:00' asDateAndTime. self assert: dt1 = dt2. self assert: dt1 asSeconds = dt2 asSeconds. "fails!"
This is bad, isn't it?
On Sat, Dec 3, 2016 at 12:50 PM, Chris Muller ma.chris.m@gmail.com wrote:
Do you know the answer to Dave's question "How many seconds elapsed between the Smalltalk epoch and the time 2004-02-29T13:33:00+02:00?"?
IOW, as long as this private, internal number is consistent for the callers, does it matter what the number is? Whether the internal "starting point" is midnight, 2am, 6am or 7:37:59am for that matter? The comment just says "1 January 1901" it does not specify a time, could we just clarify the exact time in the comment and then everything be fine?
Or is there some calculation or scenario for an application that is not consistent and correct due to this?
On Sat, 3 Dec 2016, Chris Muller wrote:
One issue appears to be that the #epoch is calculated relative to "self localOffset". So #epoch reports technically different times depending what one's #localOffset is.
|dt1 dt2| dt1:= '2004-02-29T13:33:00+02:00' asDateAndTime. dt2 := '2004-02-29T11:33:00+00:00' asDateAndTime. self assert: dt1 = dt2. self assert: dt1 asSeconds = dt2 asSeconds. "fails!"
This is bad, isn't it?
That's exactly the problem. It gets worse when your localOffset changes, or you want to use instances created in different localOffsets.
Levente
On Sat, Dec 3, 2016 at 12:50 PM, Chris Muller ma.chris.m@gmail.com wrote:
Do you know the answer to Dave's question "How many seconds elapsed between the Smalltalk epoch and the time 2004-02-29T13:33:00+02:00?"?
IOW, as long as this private, internal number is consistent for the callers, does it matter what the number is? Whether the internal "starting point" is midnight, 2am, 6am or 7:37:59am for that matter? The comment just says "1 January 1901" it does not specify a time, could we just clarify the exact time in the comment and then everything be fine?
Or is there some calculation or scenario for an application that is not consistent and correct due to this?
It sounds like we all agree that #epoch would be better as a true constant, not specific to one's timezone. If so, we should probably change it to....
epoch "Answer a DateAndTime representing the Squeak epoch: (1901-01-01T00:00:00+00:00)" ^ self julianDayNumber: SqueakEpoch offset: Duration zero
If we also revert DateAndTime>>#asSeconds back to Brent's original from 2003:
asSeconds "Return the number of seconds since the Squeak epoch" ^ (self - (self class epoch)) asSeconds
then that would fix the symmetry issue and bring us full-circle back to what Dave was saying about DateAndTimeLeapTest in the first place.
Hmm.. Magma used DateAndTime>>#asSeconds to store the integral representation of the timestamp of its commit-log records.. however, as the commit-log records are rarely consumed at all, I think this should be okay.
Does anyone else have any major impacts? Dave, you mentioned objects in the snapshot.bin files, needing a "format" conversion, what is that?
On Sat, Dec 3, 2016 at 3:19 PM, Levente Uzonyi leves@caesar.elte.hu wrote:
On Sat, 3 Dec 2016, Chris Muller wrote:
One issue appears to be that the #epoch is calculated relative to "self localOffset". So #epoch reports technically different times depending what one's #localOffset is.
|dt1 dt2| dt1:= '2004-02-29T13:33:00+02:00' asDateAndTime. dt2 := '2004-02-29T11:33:00+00:00' asDateAndTime. self assert: dt1 = dt2. self assert: dt1 asSeconds = dt2 asSeconds. "fails!"
This is bad, isn't it?
That's exactly the problem. It gets worse when your localOffset changes, or you want to use instances created in different localOffsets.
Levente
On Sat, Dec 3, 2016 at 12:50 PM, Chris Muller ma.chris.m@gmail.com wrote:
Do you know the answer to Dave's question "How many seconds elapsed between the Smalltalk epoch and the time 2004-02-29T13:33:00+02:00?"?
IOW, as long as this private, internal number is consistent for the callers, does it matter what the number is? Whether the internal "starting point" is midnight, 2am, 6am or 7:37:59am for that matter? The comment just says "1 January 1901" it does not specify a time, could we just clarify the exact time in the comment and then everything be fine?
Or is there some calculation or scenario for an application that is not consistent and correct due to this?
On Sat, Dec 03, 2016 at 04:06:10PM -0600, Chris Muller wrote:
Hmm.. Magma used DateAndTime>>#asSeconds to store the integral representation of the timestamp of its commit-log records.. however, as the commit-log records are rarely consumed at all, I think this should be okay.
Think about what would happen if someone was actively using a Magma database during a "fall back" daylight savings time transition period.
Does anyone else have any major impacts? Dave, you mentioned objects in the snapshot.bin files, needing a "format" conversion, what is that?
That is a separate topic. In UTCDateAndTime I changed the instance variables in DateAndTime, which requires considering what to do with "old format" instances that may be stored in a snapshot.bin and need to be materialized while processing the Monticello update stream that I prepared for UTCDateAndTime. I added the necessary support recently, but I will need to rebuild the update stream is there is interest in using it.
Dave
On Sat, Dec 3, 2016 at 5:12 PM, David T. Lewis lewis@mail.msen.com wrote:
On Sat, Dec 03, 2016 at 04:06:10PM -0600, Chris Muller wrote:
Hmm.. Magma used DateAndTime>>#asSeconds to store the integral representation of the timestamp of its commit-log records.. however, as the commit-log records are rarely consumed at all, I think this should be okay.
Think about what would happen if someone was actively using a Magma database during a "fall back" daylight savings time transition period.
Unless I'm missing something, that example does not relate to this. The timestamps in the logs would merely reflect the local time, which would retrace itself by one hour. A similar retracement would still occur even after we fixed this, right? The only impact I can think of is if someone wanted to restore the database to a prior point in time *within* that retraced period; in which their time specification would be ambiguous as it naturally is in the real world anyway in a fallback DST change..
Does anyone else have any major impacts? Dave, you mentioned objects in the snapshot.bin files, needing a "format" conversion, what is that?
That is a separate topic. In UTCDateAndTime I changed the instance variables in DateAndTime, which requires considering what to do with "old format" instances that may be stored in a snapshot.bin and need to be materialized while processing the Monticello update stream that I prepared for UTCDateAndTime. I added the necessary support recently, but I will need to rebuild the update stream is there is interest in using it.
I am still interested, I just have to take the time and care to convert.
On Fri, Dec 02, 2016 at 10:48:30PM +0100, Levente Uzonyi wrote:
On Fri, 2 Dec 2016, Chris Muller wrote:
It's also quit possible I'm totally confused - I did not use independent resources but was just relying on Squeak.
Well yes, of course you are confused, you should be. I would have been very worried if you looked at this and thought that it made any sense ;-)
I haven't quite groked the issue myself just yet, but you definitely sound convinced there's a tangible issue, Dave. I agree that symmetry between those two converting methods sounds like it should be..
You said the number of seconds calculated since the "epoch" is wrong but mentioned it was merely in conflict with a comment. If we "fixed" the comment, would we still have a problem?
Do you know the answer to Dave's question "How many seconds elapsed between the Smalltalk epoch and the time 2004-02-29T13:33:00+02:00?"?
Levente
In a workspace:
smalltalkEpochUntilPosixEpoch := 24 * 60 * 60 * ((52*365) + (17*366)).
posixEpochUntilJanuary2004 := 24 * 60 * 60 * ((26*365) + (8*366)).
monthOfJanuary2004 := 31 * 24 * 60 * 60.
first28DaysOfFebruary2004 := 28 * 24 * 60 * 60.
firstElevenHoursOfFebruary29 := 11 * 60 * 60.
thirtyThreeMinutesOfTheEleventhHour := 33 * 60.
totalElapsedSeconds := smalltalkEpochUntilPosixEpoch + posixEpochUntilJanuary2004 + monthOfJanuary2004 + first28DaysOfFebruary2004 + firstElevenHoursOfFebruary29 + thirtyThreeMinutesOfTheEleventhHour.
totalElapsedSeconds. "==> 3255507180"
"Below works only if UTCDateAndTime is installed, else figure it out by hand" (DateAndTime fromSeconds: totalElapsedSeconds) localOffsetSeconds: 2 * 60 * 60 ; yourself. "==> 2004-02-29T13:33:00+02:00"
On Thu, Dec 01, 2016 at 11:07:45AM +0100, Bert Freudenberg wrote:
I agree basing it on UTC makes more sense, but I'm not sure how much code would need to change, and if some stored datetimes would be affected.
Indeed, changing the instance variable format for DateAndTime does require the ability to deserialize old instances that may have been stored in the snapshot.bin of an MCZ file.
I just added this to the UTCDateAndTime project on squeaksource.com:
Name: Chronology-Core-dtl.24 Author: dtl Time: 1 December 2016, 10:20:50.201532 pm UUID: 961522d3-4d2a-42e8-bafc-f4ee338542bf Ancestors: Chronology-Core-dtl.23
Handle DataStream deserialization of old format DateAndTime by converting to the new format. This is required for reading instances that have been saved in the snapshot.bin of a Monticello MCZ archive. If deserializing the snapshot.bin works at all, then it must also handle the special case of DataAndTime instances that were serialized with the old DateAndTime instance format.
I think this handles the DataStream cases properly. Similar patches might be required for MASerializer and Fuel.
Dave
On Wed, Nov 30, 2016 at 10:51:05PM -0500, David T. Lewis wrote:
DateAndTimeLeapTest>>testAsSeconds is broken. The test passes incorrectly as a result of a false assertion:
self assert: aDateAndTime asSeconds = 3255514380.
Where aDateAndTime is specified in #setUp
aDateAndTime := (DateAndTime year: 2004 month: 2 day: 29 hour: 13 minute: 33 second: 0 offset: 2 hours).
This time is 2004-02-29T13:33:00+02:00, which in UTC is 2004-02-29T11:33:00+00:00.
The #asSeconds tests should test for elapsed seconds from the Smalltalk epoch until 2004-02-29T11:33:00+00:00. The correct number of seconds for this duration is 3255507180, not 3255514380 as asserted in the unit test.
By definition, #asSeconds is the seconds elapsed since the Smalltalk epoch (see its method comment). By common agreement, the Smalltalk epoch was defined relative to Greenwich Mean Time (UTC). If these two statements are both true, then the test is broken.
If there is no disagreement, I will fix the test and allow it to show the failure.
This thread has generated some interesting discussion, but my original question remains.
The correct number of elapsed seconds from the Smalltalk epoch to 2004-02-29T13:33:00+02:00 is 3255507180. I want to change #testAsSeconds assert this value. The test will fail, as it should.
Any objections?
Dave
On Sat, Dec 3, 2016 at 6:03 PM, David T. Lewis lewis@mail.msen.com wrote:
On Wed, Nov 30, 2016 at 10:51:05PM -0500, David T. Lewis wrote:
DateAndTimeLeapTest>>testAsSeconds is broken. The test passes incorrectly as a result of a false assertion:
self assert: aDateAndTime asSeconds = 3255514380.Where aDateAndTime is specified in #setUp
aDateAndTime := (DateAndTime year: 2004 month: 2 day: 29 hour: 13 minute: 33 second: 0 offset: 2 hours).This time is 2004-02-29T13:33:00+02:00, which in UTC is 2004-02-29T11:33:00+00:00.
The #asSeconds tests should test for elapsed seconds from the Smalltalk epoch until 2004-02-29T11:33:00+00:00. The correct number of seconds for this duration is 3255507180, not 3255514380 as asserted in the unit test.
By definition, #asSeconds is the seconds elapsed since the Smalltalk epoch (see its method comment). By common agreement, the Smalltalk epoch was defined relative to Greenwich Mean Time (UTC). If these two statements are both true, then the test is broken.
If there is no disagreement, I will fix the test and allow it to show the failure.
This thread has generated some interesting discussion, but my original question remains.
The correct number of elapsed seconds from the Smalltalk epoch to 2004-02-29T13:33:00+02:00 is 3255507180. I want to change #testAsSeconds assert this value. The test will fail, as it should.
Any objections?
How do you count non-responses? ;)
No objection from me, but since we're talking about persistent data, this deserves some good patient thought so we're sure we really want to change the meaning of #epoch to be a globalized constant rather than a timezone-specific one. If we do, then that test should be fixed along with the other two methods, too.
On Sun, 4 Dec 2016 at 01:04, David T. Lewis lewis@mail.msen.com wrote:
On Wed, Nov 30, 2016 at 10:51:05PM -0500, David T. Lewis wrote:
DateAndTimeLeapTest>>testAsSeconds is broken. The test passes
incorrectly as a
result of a false assertion:
self assert: aDateAndTime asSeconds = 3255514380.Where aDateAndTime is specified in #setUp
aDateAndTime := (DateAndTime year: 2004 month: 2 day: 29 hour: 13minute: 33 second: 0 offset: 2 hours).
This time is 2004-02-29T13:33:00+02:00, which in UTC is
2004-02-29T11:33:00+00:00.
The #asSeconds tests should test for elapsed seconds from the Smalltalk
epoch
until 2004-02-29T11:33:00+00:00. The correct number of seconds for this
duration
is 3255507180, not 3255514380 as asserted in the unit test.
By definition, #asSeconds is the seconds elapsed since the Smalltalk
epoch
(see its method comment). By common agreement, the Smalltalk epoch was
defined
relative to Greenwich Mean Time (UTC). If these two statements are both
true,
then the test is broken.
If there is no disagreement, I will fix the test and allow it to show
the failure.
This thread has generated some interesting discussion, but my original question remains.
The correct number of elapsed seconds from the Smalltalk epoch to 2004-02-29T13:33:00+02:00 is 3255507180. I want to change #testAsSeconds assert this value. The test will fail, as it should.
Any objections?
Dave
No.
- Bert -
squeak-dev@lists.squeakfoundation.org
-
Bert Freudenberg -
Chris Muller -
Chris Muller -
David T. Lewis -
Levente Uzonyi