[Pharo-project] who can have a look at Issue 5913: Remove Squeak epoch
siguctua at gmail.com
Tue Jun 19 16:50:25 EDT 2012
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 at 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 . However, the actual constant
> SqueakEpoch is actually a number of julian days, so that *could* stay
> unchanged if we decide that way.
> 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
> | 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
> 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
> 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...)
> - 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 ;-)
> 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.
More information about the Pharo-dev