[Vm-dev] Year 2037 problem

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


On Wed, May 14, 2014 at 06:49:26PM -0700, Eliot Miranda wrote:
>  
> Um...
> 
> 
> 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)"
> >
> 
> The primitives in Cog are from the Smalltalk epoch, 1901.  We still have a
> ways to go.
> 
> With 50000 years to play with the Posix epoch really makes no sense to me.
>  The start of the 20th century is a significant point time.  1970, well
> we'd already been round the moon, I was 11, hair styles were interesting,
> blah.

As previously discussed, we disagree on this point.

But that is of no real consequence. The #primitiveUTCMicrosecondClock primitive
is perfectly workable, and is suitable as a replacement for the awful microsecond
local clock that we are currently using. So please do make use of it, along
with whatever fallback code is required when running on an older VM that does
not support the primitive.

The purpose of #primitiveUtcWithOffset is different. It is a request for the
current UTC time along with the time zone offset associated with that point
in time. It is an atomic call that provides the correct local offset for any
given point in time as reported by the operating system, in particular in the
case where the offset for a point in time may change as a function of daylight
savings time transitions.

My only request is that we continue to ensure that #primitiveUtcWithOffset
exists in all VMs. I do intend to make use of it, and in fact I am working
on it now. Meanwhile, as long as this is available, I am perfectly happy if
you prefer to use #primitiveUTCMicrosecondClock rather than #primitiveUtcWithOffset.

Dave

p.s. According to the all-knowing internet, Neil Armstrong put his foot on
the moon at 2:56 UTC July 21, 1969. If we are truly unable to agree on an
an appropriate origin for the axis of time based on hair styles, then I
would like to propose Neil's footprint as a suitable alternative. It may
be another ten thousand years before such a thing occurs again.



More information about the Vm-dev mailing list