[Vm-dev] Year 2037 problem

David T. Lewis lewis at mail.msen.com
Thu May 15 03:14:37 UTC 2014


On Wed, May 14, 2014 at 06:44:39PM -0700, Eliot Miranda wrote:
>  
> On Wed, May 14, 2014 at 5:48 PM, David T. Lewis <lewis at mail.msen.com> wrote:
> 
> >
> > On Wed, May 14, 2014 at 05:34:42PM -0700, Casey Ransberger wrote:
> > >
> > > Below.
> > >
> > > > On May 13, 2014, at 10:30 AM, Eliot Miranda <eliot.miranda at gmail.com>
> > wrote:
> > > >
> > > > The [Cog] vms and the interpreter provide a 64 bit microseconds from
> > 1901 primitive which is good for > 30,000 years.
> > >
> > > Where's the method in VMMaker? Maybe I'll leave a nice comment for the
> > poor sap who gets the bug in 30,000 years:D
> > >
> >
> > There are two primitives available in all current VMs:
> >
> >    primitiveUTCMicrosecondClock
> >        "Answer the UTC microseconds since the Smalltalk epoch. The value is
> >        derived from the Posix epoch (see primitiveUTCMicrosecondClock)
> > with a
> >        constant offset corresponding to elapsed microseconds between the
> > two
> >        epochs according to RFC 868."
> >
> >    primitiveUtcWithOffset
> >        "Answer an array with UTC microseconds since the Posix epoch and
> >        the current seconds offset from GMT in the local time zone. An empty
> >        two element array may be supplied as a parameter.
> >        This is a named (not numbered) primitive in the null module (ie the
> > VM)"
> >
> 
> In which case are we in agreement that it's time I replace the old
> primitive use with the new ones in trunk?
> 

Definitely yes, but if and only if the fallback code is implemented such that
people using older VMs will still have functioning images.

Dave



More information about the Vm-dev mailing list