[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