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

[David T. Lewis]

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.

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.

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

>  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.

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

Thanks,
Dave