It should be a great party, I'll put it on my calendar!

But the year 60,000 shouldn't be a problem for programmers. All we need
to do is get everybody to start using sensible software such as Squeak:

  '60000-01-01T00:00:00-00:00' asDateAndTime ==> 60000-01-01T00:00:00+00:00

Of course, from what I know about programmers, it will probably take
another 60,000 years to convince them to start using sensible software.

;-)
Dave


On Wed, Apr 29, 2020 at 11:02:17AM -0400, Ron Teitelbaum wrote:
> Can I just say now that I think the year 60,000 will be a bad year for
> programmers!
> 
> (Sorry couldn't resist.  We're gonna party like it's Fifty Nine Nine
> Ninety Nine!)
> 
> Ron
> 
> On Wed, Apr 29, 2020 at 5:18 AM Eliot Miranda <eliot.miranda at gmail.com>
> wrote:
> 
> > Hi Chris, Hi Dave,
> >
> > > On Apr 28, 2020, at 5:53 PM, Chris Muller <asqueaker at gmail.com> wrote:
> > >
> > > ???
> > > I have a bunch of two-element Array log entries, where the first element
> > is the timestamp, the second is the object being logged.  But these entries
> > may never be consumed, so I wish to minimize their cost.  So, instead of
> > storing the timestamps as DateAndTimes, I wanted to keep them as
> > SmallIntegers.  I thought I could use Time utcMicroseconds, now a
> > SmallInteger in 64-bit Squeak.
> > >
> > > However, when I went to instantiate the DateAndTime lazily from that
> > number it's said it's year 2089...
> > >
> > >         DateAndTime utcMicroseconds: Time utcMicrosecondClock offset: 0
> >    " 2089-04-29T00:49:26.3326+00:00"
> >
> > I gave yo say that this is a bug.  Dave, I know you have affection for the
> > posix epoch but the system uses the Smalltalk epoch, the start of the 20th
> > c, and the utcMucroseconds primitive answers microseconds from that epoch,
> > not the posix epoch.  And it???s good for some 58,000 years before it
> > overflows 61-bit SmallIntegers (there are three tag bits) so there???s
> > essentially nothing to be gained from using the posix epoch.
> >
> > Now the posix epoch is important; and we should support it.  But we should
> > clearly indicate it in spud, eg by having the word posix in the selector
> > somewhere.
> >
> > So the method should be renamed either utcPosixMicroseconds:offset: or
> > posixUTCMicroseconds:offset:, and utcMicroseconds:offset: should go what
> > Chris expects.  The principle of least astonishment says it must be so.
> >
> >
> > >
> > > I realized this is because a different epoch being used (1901 vs. 1971)
> > between the two.  This seems inconsistent and confusing, but that's less
> > important to me at the moment than the efficiency I'm looking for.  Is
> > there another way?
> > >
> > >  - Chris
> > >
> >
> >

>