Hi Bert,

> On Feb 17, 2016, at 6:56 PM, Bert Freudenberg <bert at freudenbergs.de> 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).

I like the idea of deriving it.  Having reliance in the old prim seems weak to me.  Logically the milliseconds since startup can be derived from microseconds.  The latest VMs answer the value of the utcMicrosecondClock at start up via vmParameterAt: N (can't remember N).  So in eg Delay startUp: the system could query the utcMicrosecondClock at start up via vmParameterAt and if the query fails just use utcMicrosecondClock now and store this in a variable and answer the millisecond clock by subtracting this from utcMicrosecondClock.

In new VMs I can also make the event time stamps agree with this.

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

I wish David had never introduced this.  The Smalltalk epoch is fine.  Why do we need other than utcMicrosecondClock and localMicrosecondClock?  We can derive posix times from utcMicrosecondClock trivially.  There is some concern about the cost of large integer arithmetic but in practice the cost is negligible because the system spends tiny amounts of time computing times and lots of time doing useful stuff in between.

> 
> - Bert -
> 
> 
> 
>