On Wed, Feb 17, 2016 at 06:56:58PM -0800, Bert Freudenberg wrote:
> 
> > On 17.02.2016, at 17:13, tim Rowledge <tim at rowledge.org> wrote:
> > 
> > a) primMicrosecondClock is not sent in a 5.0 image and seems to only be implemented in a plain interpreter VM.
> > b) primMillisecondClock/135 is not sent in a 5.0 image
> > c) eventMillisecondClock/135 is used for the faked-up events required for double-click handling
> > d) primPosixMicrosecondClockWithOffset is not sent in 5.0
> > e) primUTCMicrosecondClock/240 is not sent in 5.0 - would return uSec value in raw
> > f) localMicrosecondClock/241 is used in 5.0 in particular from Time now (as per the ClockMorph)
> > g) utcMicrosecondClock/240 is used in 5.0 for Delays and timing type cases
> > h) primSecondsClock/137 isn???t used in 5.0
> > i) primMillisecondClockMask isn???t used in 5.0
> > j) primLocalMicrosecondClock/241 isn???t used in 5.0
> > 
> > So we have quite a collection of mixedup terminology and unused methods to clear up!
> > 
> > Looking at it from the prims point of view -
> > 
> > Prim 135 is needed in order to provide the same timebase as the events coming in, so we can???t drop that, and it affects nothing else.
> > 
> > Prim 240 is for no-TZ microseconds and is used in Delay etc but crucially as part of DateAndTime>now which is why we are having a problem in the latest updated 5.0 with no TZ/Locale being used.
> > Prim 241 is used by Time now etc and includes the TZ offset, which is why Time now returns correct wall-clock time.
> > 
> > The others are no longer used and could be removed except for the primPosixMicrosecondClockWithOffset which we ought to make use of so that the TZ is reported back.
> 
> I think we should go back to prim 135 for millisecondClockValue (or maybe possibly derive it from prim 240).

All other things equal, I would think it is better to use prim 135 because
that has been a required primitive all along.

> 
> Time now should use primPosixMicrosecondClockWithOffset to be exactly equivalent to what DateAndTime now does. (unless the VM is fixed to use the exact same mechanism for both) Even better would be a localMicrosecondClockWithOffset primitive that could do that method???s work without LargeInt arithmetic.
> 

In the limited testing that I have done, the use of large integers as
return values for time primitives make very little difference. And with
the Spur object format, it becomes irrelevant. So I don't think we need
to worry about that.

Dave