[Vm-dev] Re: [Pharo-project] who can have a look at Issue 5913: Remove Squeak epoch

[Eliot Miranda]

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
> 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.
> >
>
>
>
> --
> Best regards,
> Igor Stasenko.
>
>


-- 
best,
Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20120619/94268535/attachment-0001.htm