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

[Eliot Miranda]

On Mon, Aug 23, 2010 at 11:32 AM, Nicolas Cellier <
nicolas.cellier.aka.nice at gmail.com> wrote:

>
> 2010/8/23 Eliot Miranda <eliot.miranda at gmail.com>:
> >
> >
> >
> > 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.
>
> Or maybe milliseconds / 1000 or microseconds / 1000000 ?
>

Doh!  Indeed I meant "Time seconds = Time microseconds // 1000000".  Monday
mornings ;)


>
> > 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/3bbf4a5b/attachment.htm