<div dir="ltr">Log entries are created often, I actually want to avoid creation of an interim DateAndTime in the first place.  I'm not even concerned about storage yet, but that will also benefit later.<div><br></div><div>Wait a second.  The Squeak epoch is only one year different than the posix epoch, right?  So why am I getting 2089 instead of something within 1 year of 2020?</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Apr 28, 2020 at 9:07 PM David T. Lewis <<a href="mailto:lewis@mail.msen.com" target="_blank">lewis@mail.msen.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Tue, Apr 28, 2020 at 07:53:05PM -0500, Chris Muller wrote:<br>
> I have a bunch of two-element Array log entries, where the first element is<br>
> the timestamp, the second is the object being logged.  But these entries<br>
> may never be consumed, so I wish to minimize their cost.  So, instead of<br>
> storing the timestamps as DateAndTimes, I wanted to keep them as<br>
> SmallIntegers.  I thought I could use Time utcMicroseconds, now a<br>
> SmallInteger in 64-bit Squeak.<br>
> <br>
> However, when I went to instantiate the DateAndTime lazily from that number<br>
> it's said it's year 2089...<br>
> <br>
>         DateAndTime utcMicroseconds: Time utcMicrosecondClock offset: 0<br>
> " 2089-04-29T00:49:26.3326+00:00"<br>
> <br>
> I realized this is because a different epoch being used (1901 vs. 1971)<br>
> between the two.  This seems inconsistent and confusing, but that's less<br>
> important to me at the moment than the efficiency I'm looking for.  Is<br>
> there another way?<br>
> <br>
>  - Chris<br>
<br>
Store the time in units of milliseconds or microseconds relative to the<br>
Posix epoch. This is an integer value (small integer in 64 bit Spur), and<br>
it a common time basis in many operating system and database libraries,<br>
so it is well understood and well defined.<br>
<br>
At higher levels of precision (e.g. nanosecond), the value is not an<br>
integer, but that is perfectly all right, just think of it as a Number<br>
that is usually an integer in common use cases. If  you need to store<br>
it in the database as an integer, just round it off to the nearest<br>
millisecond or microsecond (whichever you have chosen).<br>
<br>
Microsecond precision is probably a good choice. This would be measured<br>
as microseconds elapsed since the Posix epoch. That gives you small<br>
integer values on Spur 64 for reasonable time values, and it is a higher<br>
level of precision than you will probably ever need.<br>
<br>
Assuming that you want to use a measurement scale of seconds relative to<br>
Posix epoch, and assuming also that you want to measure this in units<br>
of microseconds, then:<br>
<br>
        | now uSecRelativeToPosixEpoch newInstance |<br>
        now := DateAndTime now.<br>
        uSecRelativeToPosixEpoch := now utcMicroseconds.<br>
        newInstance := DateAndTime utcMicroseconds: uSecRelativeToPosixEpoch offset: 0.<br>
        now = newInstance "==> true"<br>
<br>
<br>
Dave<br>
<br>
</blockquote></div>