On Wed, Apr 29, 2020 at 02:18:17AM -0700, Eliot Miranda 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.
> 

Currently we have this:

    DateAndTime class>>utcMicroseconds: microsecondsSincePosixEpoch offset: secondsFromGMT
        ^super new
            utcMicroseconds: microsecondsSincePosixEpoch
            offset: secondsFromGMT

No objection from me if you want to change the method name, and
I think posixUTCMicroseconds:offset: would be a good choice if you
want to do that. The original rationale for the name of this constructor
is simply that it matches the instance variable names.

If there is still a method called utcMicroseconds:offset: then please
do *not* give it different semantics.

Dave


> 
> > 
> > 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
> > 
>