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

[David T. Lewis]

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.

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.

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.

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))
> >
> >
> > =============================================
> >
> >