[Vm-dev] Year 2037 problem

Eliot Miranda eliot.miranda at gmail.com
Tue May 13 17:30:55 UTC 2014


Hi Bert,

This is already taken care of for the next release, and old images should hopefully be a non issue by 2037 (if one does need to run an old image some hack can be arranged, change the clock, fake the clock, whatever).

The Cig vms and the interpreter provide a 64 bit microseconds from 1901 primitive which is good for > 30,000 years.  I'll be making the change to this time saw in 4.6/5.0.  It solves a number of issues, including no longer needing to sync the second and millisecond clocks at startup because both are derived from the microsecond clock, which can save 0.5 secs on startup.

Eliot (phone)

On May 13, 2014, at 6:21 AM, Bert Freudenberg <bert at freudenbergs.de> wrote:

> Our primitiveSecondsClock implementation uses 32 bits. It is only a VM-internal problem, the image always sees a LargeInteger anyway. But the current implementation will overflow in 2037. 
> 
> This is similar to Unix's year 2038 problem:
>    http://en.wikipedia.org/wiki/Year_2038_problem
> But Squeak's epoch is different and we're using seconds, not milliseconds.
> 
> Nothing to worry about for a while, but at some point the VMs need be updated, to support images that still use that primitive :)
> 
> - Bert -
> 


More information about the Vm-dev mailing list