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

----- Forwarded message from Eliot Miranda eliot.miranda@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@gmail.com To: "David T. Lewis" lewis@mail.msen.com

On Tue, Aug 24, 2010 at 11:07 AM, David T. Lewis lewis@mail.msen.comwrote:

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