[squeak-dev] efficient DateAndTime

Eliot Miranda eliot.miranda at gmail.com
Wed Apr 29 09:18:17 UTC 2020


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
> 


More information about the Squeak-dev mailing list