IMO epoch starting is completely orthogonal to timezone bug which should simply fixed. If you define epoch time as 1 jan 1970 (or any other date you prefer) but still will mess up with timezones, it won't change anything isn't? 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-tp4630581p...
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-... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
-- Best regards, Igor Stasenko.