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.

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?


On Tue, Apr 28, 2020 at 9:07 PM David T. Lewis <lewis at mail.msen.com> wrote:

> On Tue, Apr 28, 2020 at 07:53:05PM -0500, Chris Muller 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 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
>
> Store the time in units of milliseconds or microseconds relative to the
> Posix epoch. This is an integer value (small integer in 64 bit Spur), and
> it a common time basis in many operating system and database libraries,
> so it is well understood and well defined.
>
> At higher levels of precision (e.g. nanosecond), the value is not an
> integer, but that is perfectly all right, just think of it as a Number
> that is usually an integer in common use cases. If  you need to store
> it in the database as an integer, just round it off to the nearest
> millisecond or microsecond (whichever you have chosen).
>
> Microsecond precision is probably a good choice. This would be measured
> as microseconds elapsed since the Posix epoch. That gives you small
> integer values on Spur 64 for reasonable time values, and it is a higher
> level of precision than you will probably ever need.
>
> Assuming that you want to use a measurement scale of seconds relative to
> Posix epoch, and assuming also that you want to measure this in units
> of microseconds, then:
>
>         | now uSecRelativeToPosixEpoch newInstance |
>         now := DateAndTime now.
>         uSecRelativeToPosixEpoch := now utcMicroseconds.
>         newInstance := DateAndTime utcMicroseconds:
> uSecRelativeToPosixEpoch offset: 0.
>         now = newInstance "==> true"
>
>
> Dave
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200428/5b3f3cc4/attachment.html>