[Vm-dev] Re: [Pharo-project] who can have a look at Issue 5913:
Remove Squeak epoch
eliot.miranda at gmail.com
Tue Jun 19 22:32:47 UTC 2012
On Tue, Jun 19, 2012 at 1:50 PM, Igor Stasenko <siguctua at gmail.com> wrote:
> 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?
+1. In Cog the VM has a 64-bit microsecond clock which is available both
as microseconds from 1901 UTC and in local time. This is a great basis as
it eliminates millisecond clock rollover issues (every 49 days?), lasts for
> 50,000 years, and needs only the one primitive to answerUTC in up to
microsecond resolution, fully synchronised. VW has been using such a basis
for about a decade. If we could add these time primtiievs to the
Interpreter IMO we'd have a much better basis for time.
> 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
> > was cloudy (IMO wrong) from the beginning . However, the actual
> > 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
> >>> 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
> > image:
> > testSqueakEpochClock
> > | secondsFromClock secondsSinceEpochUTC |
> > self useTimeZone: 'EDT' during: [
> > secondsFromClock := Time primSecondsClock.
> > secondsSinceEpochUTC := (DateAndTime now -
> > asDateAndTime) asSeconds.
> > "Fails because the clock returns the number of seconds
> > 1901-01-01T00:00:00+(localOffset)"
> > self deny: secondsFromClock = (secondsSinceEpochUTC +
> > 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
> > 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
> > 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
> > I'll do... I'm going to create a new issue and to fix the image-side
> > 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:
> > Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
> Best regards,
> Igor Stasenko.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Vm-dev