[squeak-dev] DateAndTimeLeapTest>>testAsSeconds is broken

Chris Muller 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:
     ^ self
          julianDayNumber: SqueakEpoch
          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.
> Levente
>> On Sat, Dec 3, 2016 at 12:50 PM, Chris Muller <ma.chris.m at 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?

More information about the Squeak-dev mailing list