[squeak-dev] A UTC based implementation of DateAndTime

J. Vuletich (mail lists) juanlists at jvuletich.org
Mon May 26 18:16:03 UTC 2014


Quoting "David T. Lewis" <lewis at mail.msen.com>:

> ...
>>
>
> Ian did a build of the Windows VM that should have the necessary support. Try
> the Squeak4.1.2.2612 VM from http://squeakvm.org/win32/.

That VM fails for
	<primitive: 'primitiveUtcWithOffset'>
	<primitive: 240> primUtcMicrosecondClock
	<primitive: 241> primLocalMicrosecondClock

> One thing to note - if the primitive is not present, DateAndTime will fall
> back on the old logic, and it should produce reasonable results.

Yes, Cuis already does that... I'd prefer to be able to assume that  
any future VM will provide 	<primitive: 'primitiveUtcWithOffset'> and  
clean the code. Would that asking for too much?

>> Additionally, besides getting rid of <primitive: 137>
>> (primLocalSecondsClock that will overflow in 2037), it would be great
>> to stop using <primitive: 135> (primLocalSecondsClock), that overflows
>> every six days. But for this, we would need a new <primitive: 136>
>> (primSignal:atMilliseconds:) as it uses on the same time base. This
>> would enable a serious simplification of Delay.
>>
>
> I think that Eliot is planning to update Squeak to use the microsecond clock
> primitive, which removes any 2037 issues. I'm not sure if that would include
> a change to primSignal:atMilliseconds:
>
> Dave

I see. But given that the Delay code is fragile and not trivial at  
all, the advantages of of relying on a clock that never rolls over  
would be significant.

Please, Eliot, consider this when you work on this code.


Cheers,
Juan Vuletich



More information about the Squeak-dev mailing list