Quoting "David T. Lewis" lewis@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