[squeak-dev] efficient DateAndTime

Ron Teitelbaum ron at usmedrec.com
Wed Apr 29 15:02:17 UTC 2020


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
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200429/44b08d24/attachment.html>


More information about the Squeak-dev mailing list