Use of UTC and offset for system clock (was: [Vm-dev] Re: [squeak-dev] Daily Commit Log)

[Eliot Miranda]

On Sun, Aug 22, 2010 at 7:39 PM, David T. Lewis <lewis at mail.msen.com> wrote:

>
> Eliot,
>
> Yes, it can be retracted. I may not get to it for a few days so feel
> free to do so on my behalf. I introduced the change in trunk to put
> some visibility on the new primitives, which appears to have achieved
> the intended purpose ;)
>
> With respect to the Squeak epoch, we do have an issue that needs to
> be clarified. In the Squeak implementation, we have the 1901 epoch,
> but AFAIK there is no specification of the time zone in which the epoch
> is defined. In the Squeak implementation, local time has consistently
> been used in the platform interface, and the actual values of the
> Squeak clock for any real point in time are different depending on
> the time zone in which the image happens to be running.
>

It's implicit that it is GMT/UTC.  So the Squeak epoch is the start of 1901
in Greenwich.

To put it another way, there is no such thing as "UTC & local
> microseconds from the Smalltalk epoch" unless there is a clearly
> defined transformation between the Smalltalk epoch and the posix
> epoch, and in practice (in Squeak at least) this is not the case.
> Midnight on January 1, 1901 in Palo Alto, California was a different
> point in time from midnight January 1, 1901 in London, and I cannot
> determine which of the two was the "real" Smalltalk epoch.
>

The latter is the only one that makes good sense.


> This begs the question of why, in implementing the interface to
> the underlying platform, we would *not* want use the posix epoch
> as a reference point. The Posix epoch is well defined, well documented,
> well understood, and easily translated to any existing definition of
> the Smalltalk epoch. In contrast, the Smalltalk epoch is ambiguously
> defined, poorly documented, and widely misunderstood.
>

I think its easy to fix; just define it to be the start of the 20th century
in UTC.  That's what we did with VW and its easy to do with Squeak.  For me
backwards compatibility pushes strongly for keeping with the Squeak epoch,
i.e. Time seconds = Time milliseconds / 1000000.

best,
Eliot


>
> Dave
>
> On Sat, Aug 14, 2010 at 05:28:28PM -0700, Eliot Miranda wrote:
> >
> > Hi David,
> >
> >     any chance of getting you to retract this?  The Cog VM has 64-bit UTC
> &
> > local microseconds from the Smalltalk epoch (1901), which are hence
> easier
> > to use as a basis for the Squeak clock and still last for ~ 54,000 years.
> >  I'd like to see the Cog and standard VMs converge on a primitive set.
>  This
> > is an issue for me since changing the epoch is, I think, an unnecessary
> > change.
> >
> > best
> > Eliot
> >
> > On Sat, Aug 14, 2010 at 4:55 PM, <commits at source.squeak.org> wrote:
> >
> > > Changes to Trunk (http://source.squeak.org/trunk.html) in the last 24
> > > hours:
> > >
> > >
> > >
> http://lists.squeakfoundation.org/pipermail/packages/2010-August/003596.html
> > >
> > > Name: Kernel-dtl.476
> > > Ancestors: Kernel-eem.475
> > >
> > > Add Time class>>primMicrosecondClock and Time class>>primUtcWithOffset
> for
> > > access to microsecond clock primitives available in newer Squeak VMs.
> > >
> > > primMicrosecondClock provides a system clock with nominal microsecond
> > > precision.
> > >
> > > primUtcWithOffset answers UTC time as microseconds since the Posix
> epoch
> > > and offset as seconds offset from GMT. The Squeak clock is
> traditionally
> > > implemented in terms of platform local time. Use of UTC time and offset
> is
> > > advantageous if time zones and daylight saving time offsets are to be
> > > considered.
> > >
> > > Example:
> > > { Time primMillisecondClock .
> > >   Time primMicrosecondClock .
> > >   Time primUtcWithOffset } ==> #(6932757 6932757830 #(1281815075538304
> > > -14400))
> > >
> > >
> > > =============================================
> > >
> > >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20100823/9a4ea1b4/attachment.htm