On 19 June 2012 21:53, Sean P. DeNigris <
sean@clipperadams.com> wrote:
> I wrote some tests to show the broken behavior. I'm attaching them to the
> issue and
>
http://forum.world.st/file/n4635557/DateAndTimeTest-test_-_epoch.st to
> Nabble . Comments inline below...
>
>
> Eliot Miranda-2 wrote
>>
>>> We recently agreed that the Squeak epoch was well-defined, i.e. the
>>> start of the 20th century in GMT. This is clear if you read the
>>> SMalltalk-80 V2 sources. The reason advanced for changing to Unix was
>>> that the Squeak epoch is not well-defined. That argument is incorrect.
>>
>
> My understanding of what we found was that ST-80 referenced GMT, but Squeak
> was cloudy (IMO wrong) from the beginning [1]. However, the actual constant
> SqueakEpoch is actually a number of julian days, so that *could* stay
> unchanged if we decide that way.
>
> [1]
>
http://forum.world.st/Re-Pharo-project-Epoch-returns-local-offset-tp4630581p4630834.html
>
>
> Eliot Miranda-2 wrote
>>
>>> Further, the Squeak epoch is embedded in the VMs, in their answering both
>>> seconds and microseconds from the epoch. So there's work involved in
>>> getting rid of it.
>>
> This test indicates to me that the VM is using the same (wrong) logic as the
> image:
> testSqueakEpochClock
>
> | secondsFromClock secondsSinceEpochUTC |
> self useTimeZone: 'EDT' during: [
> secondsFromClock := Time primSecondsClock.
> secondsSinceEpochUTC := (DateAndTime now - '1901-01-01T00:00:00+00:00'
> asDateAndTime) asSeconds.
>
> "Fails because the clock returns the number of seconds since
> 1901-01-01T00:00:00+(localOffset)"
> self deny: secondsFromClock = (secondsSinceEpochUTC + DateAndTime
> localOffset asSeconds).
> self assert: secondsFromClock equals: secondsSinceEpochUTC ].
>
>
> Stéphane Ducasse wrote
>>
>> Now Sean what was your problem? Because may be we can also improve
>> Squeak-epoch.
>>
> Any time a DateAndTime is converted to seconds, the result is "the number of
> seconds since 1901-01-01T00:00:00+(localOffset)", which is indeterminate.
> For example (see #testSqueakEpochAcrossTimeZones):
> 1. aDateAndTime asSeconds.
> 2. quit the image
> 3. move to a different time zone (or set localTimeZone: to a different tz)
> 4. open the image again
> 5. restore the DateAndTime e.g. #fromSeconds:
> It is a different DateAndTime!!
>
> I'm clear (but please review the tests) that whatever epoch we choose:
> - the implementation *around* it must be fixed
> - the VM should be changed
> - any existing integers representing DateAndTime's will be invalid
>
> I think the only reason we've gotten this far without anyone noticing is
> that they are converted to/from integers in the same incorrect way in both
> directions, so unless you transport live instances into a different time
> zone, you would never notice.
>
> The only question that I see we've come down to is:
> - keep the Squeak epoch, because it is elegant (turn of the century...)
> or
> - use the Unix epoch, because it is well-known and documented
> This is honestly much less important than the givens above, so this is what
> I'll do... I'm going to create a new issue and to fix the image-side issues
> I mentioned, and we can have fun debating this last question, which seems to
> come down to style, ad infinitum ;-)
>
> Sean
>
> --
> View this message in context:
http://forum.world.st/who-can-have-a-look-at-Issue-5913-Remove-Squeak-epoch-tp4634003p4635557.html
> Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
>