[squeak-dev] DateAndTimeLeapTest>>testAsSeconds is broken
asqueaker at gmail.com
Sat Dec 3 22:06:10 UTC 2016
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....
"Answer a DateAndTime representing the Squeak epoch:
offset: Duration zero
If we also revert DateAndTime>>#asSeconds back to Brent's original from 2003:
"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
On Sat, Dec 3, 2016 at 3:19 PM, Levente Uzonyi <leves at 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.
>> On Sat, Dec 3, 2016 at 12:50 PM, Chris Muller <ma.chris.m at gmail.com>
>>>> Do you know the answer to Dave's question "How many seconds elapsed
>>>> 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?
More information about the Squeak-dev