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

Tue Aug 24 16:43:54 UTC 2010

Hi David,

On Tue, Aug 24, 2010 at 5:24 AM, David T. Lewis <lewis at mail.msen.com> wrote:

> Eliot,
>
> I am afraid that I may have misunderstood your original request
> to retract the change.
>
> I assumed that you were refering to Time class>>primUtcWithOffset
> that I had added to trunk (and I did remove that method), but
> in rereading your note I think you may have been referring to
> the earlier VMMaker updates that introduced the primitives
> #primitiveMicrosecondClock and #primitiveUtcWithOffset. In
> particular, #primitiveMicrosecondClock seems similar to the
> Cog primitives, which include #primitiveUTCMicrosecondClock
> and #primitiveLocalMicrosecondClock.
>
> Apologies for my misunderstanding, but can you please clarify
> which methods you were suggesting should be retracted?
>
>        Interpreter>>primitiveMicrosecondClock
>        Interpreter>>primitiveUtcWithOffset
>        Time class>>primMicrosecondClock
>        Time class>>primUtcWithOffset
>

If primitiveMicrosecondClock answers 64-bit UTC microseconds since 1901 this
is the same as Cog's primitiveUTCMicrosecondClock and should be retained.
 It also needs a 64-bit local microseconds since 1901 which would be the
same as Cog's primitiveLocalMicrosecondClock and a
primitiveSignalAtUTCMicroseconds which is for 64-bit microseconds since 1901
what primitiveSignalAtMilliseconds is for 30-bit wrapping milliseconds
(again see Cog).  We then need to agree on some primitive numbers or
primitive names.  In Cog these three are

(240 primitiveUTCMicrosecondClock) "was serial port primitive"
(241 primitiveLocalMicrosecondClock) "was serial port primitive"
(242 primitiveSignalAtUTCMicroseconds)

Cog also has
(243 primitiveUpdateTimezone) "primStringtranslatefromtotable"

primitiveUpdateTimezone
"Update the VMs notion of the current timezone.  The VM sets its notion
 of the timezone once at start-up.  If one wants the VM to keep its notion
 up-to-date arrange to invoke this primitive periodically."
self ioUpdateVMTimezone

which causes the VM to reevaluate the delta between UTC and local
microseconds.

With these four one has a non-wrapping synchronised timebase with
potentially microsecond resolution that marries well with Squeak's 64-bit
integer support.  This approach worked very well for VisualWorks where we
got rid of lots of customer problems every 49.7 days (2^32 milliseconds).
 There has been some concern expressed about the performance impact of long
integers but at least in VW that simply wasn't an issue.

best
Eliot

> Thanks,
> Dave
>
>
> On Mon, Aug 23, 2010 at 11:04:57AM -0700, Eliot Miranda wrote:
> >
> > 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/20100824/fd02af8b/attachment.htm