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

[David T. Lewis]

Eliot had intended to CC the list (personal communication) so I am
forwarding his reply here:

----- Forwarded message from Eliot Miranda <eliot.miranda at gmail.com> -----

Date: Tue, 24 Aug 2010 12:09:18 -0700
Subject: Re: Use of UTC and offset for system clock (was: [Vm-dev] Re: [squeak-dev] Daily Commit Log)
From: Eliot Miranda <eliot.miranda at gmail.com>
To: "David T. Lewis" <lewis at mail.msen.com>

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

> On Tue, Aug 24, 2010 at 09:43:54AM -0700, Eliot Miranda wrote:
> > 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.
>
> primitiveMicrosecondClock is like primitiveMillisecondClock in that
> it answers a value that rolls over periodically, and it not a measure
> of duration relative to any epoch. The extra precision is of course
> meaningless for any individual call, but apparently is of value when
> taken cumulatively for purposes of profiling. I will have to defer
> to John as to whether it can or should be replaced by
> primitiveUTCMicrosecondClock.
>
> In any case, the meanings of primitiveMicrosecondClock and
> primitiveUTCMicrosecondClock are different, and I should think
> that they could safely coexist as long as we give them detailed
> method comments to explain the time basis for each.
>

Indeed.  Except for me a clock that wraps at least every 1 hour 11 minutes
and 35 seconds doesn't seem that easy to use ;)


> As long as you have no objection, I strongly prefer to retain
> primitiveUtcWithOffset in its current form, regardless of whether
> it actually gets used for anything near term. It's something that
> Lex Spoon proposed ten years ago and it's near and dear to my heart
> after my experience implementing the TimeZoneDatabase.
>

That's no problem.


> I note that I should change the primitive name in SqueakVM from
> "primitiveUtcWithOffset" to "primitiveUTCWithOffset" for consistency.
>

Agreed.


> >  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).
>
> OK. And I would see no reason not to add these to the traditional SqueakVM
> as well. If you have specific suggestions as to which of the new Cog
> primitives should go into SqueakVM for consistency, that would help.
> I am assuming that at some point we want the Squeak trunk to start making
> use of the new Cog primitives, and that therefore they should also made
> available in the traditional SqueakVM.
>

I would add all 4 of these new 64-bit time primitives to the existing VM,
perhaps holding off to implement the idea of cacheing previous results to
answer new result objects only when the time actually changes.  The point
being that such a single time basis has lots of benefits for image level
code (see John's message later in this thread ;) ).


>
> > 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.
> >
>
> At this point, primitiveMicrosecondClock and primitiveUtcWithOffset
> are not numbered primitives, and I see no need for them to be numbered.
> As far as I know, no one else has plans to consume additional primitive
> numbers, so we are following your lead with respect to assigning
> primitive numbers (and I should update the SqueakVM table accordingly).
>

Yes, we need to do a merge of the tables.  I'm going to discuss this with
John real soon now.


>
> Thanks,
> Dave
>
>

----- End forwarded message -----