> On 17.02.2016, at 20:10, Eliot Miranda <eliot.miranda at gmail.com> wrote:
> 
> 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:
>>> 
>>> 
>>> 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.

Sounds good.

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

It's not about the time base (Smalltalk would be preferable indeed) but an atomic call giving  current time and offset. As I wrote, localMicrosecondClockWithOffset would be ideal.

- Bert -
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6112 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20160217/ad682a29/smime.bin