[squeak-dev] UTCDateAndTime discussion + Q&A

David T. Lewis lewis at mail.msen.com
Sat Oct 27 14:18:22 UTC 2018


Hi Chris,

On Fri, Oct 26, 2018 at 10:26:20PM -0500, Chris Muller wrote:
> > What's your feeling overall regarding UTCDateAndTime? Does it seem like
> > a worthwhile change from your point of view? And to my main worry, is
> 
> I would expect the storage and performance advantage of UTCDateAndTime
> to be muted in 32-bit Squeak.  Chronology breaking down the "point" of
> a point-in-time into 3 SmallIntegers -- days, seconds, nanos   (days
> a.k.a., 'jdn') means there's always just three object pointers for
> that.  50-bits for #utcMicroseconds in a 32-bit image, however, may be
> nearly as expensive.
> 
> But since SmallIntegers run well beyond 50-bits in 64-bit Squeak, I
> would expect a slight performance and storage advantage.

To check performance, you can use the DateAndTimePerformance package
in the http://www.squeaksource.com/UTCDateAndTime repository. I think
you will be pleased with the results, although I have only run it on
Linux so it would be good to check Windows and OSX also.

> 
> There's also the claimed understandability advantage, which is
> something, but somewhat offset by the conversion / compatibility
> issues users must face and endure.  "Worthwhile" is definitely the key
> question we need to decide.  For me, it seems worth it in theory
> because it seems like it shouldn't be too hard to convert.  The only
> way to find out is to attempt to convert one of my most date-intensive
> applications (including database) see how it goes, see what issues
> arise.
> 
> > there anything about the different layout of instance variables that is
> > likely to cause problems for Magma, or for applications that use other
> > databases for persistence? I think that it will be OK, but it's better
> > to ask now than to be sorry later.
> 
> There is the layout, there is also the hash calculation.  Could you
> make it the same as in Chronology?  It could ease migration, but we
> want it to remain fast.

The hash in the UTCDateAndTime version is:

  DateAndTime>>hash
      ^utcMicroseconds hash

I don't know if this is a good hash function, although it at least
has the virtue of simplicity.

I expect we could make it compatible with the existing function if
that is a better thing to do, although it might have some performance
impact.

> 
> We need to think about how different migrations could and should work.
> Bulk conversions?  Lazy migrations?  We may need some way for apps to
> be able to (quickly) ask if they're running the new UTCDateAndTime or
> the old Chronology, to help support those...

Some kind of test like "DateAndTime instVarNames size" should work.

Dave


> >
> > >
> > > On Mon, Oct 22, 2018 at 10:22 PM David T. Lewis <lewis at mail.msen.com> wrote:
> > > >
> > > > On Mon, Oct 22, 2018 at 09:02:57PM -0400, David T. Lewis wrote:
> > > > > Hi Chris,
> > > > >
> > > > > On Mon, Oct 22, 2018 at 04:30:52PM -0500, Chris Muller wrote:
> > > > > > Hi Dave,
> > > > > >
> > > > > > Thanks for making UTCDateAndTime available on SqueakMap that "just
> > > > > > works" -- not having to go research how to properly install it left me
> > > > > > some time to actually start looking at it today.
> > > > > >
> > > > > > A cursory look reveals that, at least functionally, everything appears
> > > > > > to be essentially the same as original Chronology except the on-going
> > > > > > million-dollar question:
> > > > > >
> > > > > >              What are the point-in-time endpoints of a timespan
> > > > > > identified by a particular "Date"?
> > > > > >              There are two reasonable answers to this question:
> > > > > >
> > > > > >                  1) "local" e.g., a period that begins from 12am to
> > > > > > 11:59:59.999999 of my LOCAL time,
> > > > > >              or 2) "global" e.g., a period that begins from 12am to
> > > > > > 11:59:59.999999 of UTC (offset 0).
> > > > > >
> > > > > > We already know that original Chronlology supports ability for
> > > > > > applications to represent their Dates either way.  What about
> > > > > > UTCDateAndTime?   When I do:
> > > > > >
> > > > > >         DateAndTime now asDate = Date today
> > > > > >
> > > > > > I get "true", even though MY 22-Oct-2018 begins and ends at a
> > > > > > different point-in-time than those in the UTC timezone..
> > > > > >
> > > > > > I realize most applications want a canonical representation of Dates,
> > > > > > but where does this leave the timespan use-cases?  Are they even
> > > > > > possible at all?   What if I truly need the same local representation
> > > > > > of  22-Oct-2018 that everyone else recognizes in my local area?
> > > > > >
> > > > >
> > > > > I think the difference is when we get to Date class>>starting: which
> > > > > sets the starting point to be aDateAndTime midnight.
> > > > >
> > > > > In classic Chronology:
> > > > >   DateAndTime now asDate start ==> 2018-10-22T00:00:00-04:00
> > > > >
> > > > > In UTCDateAndTime Chronology:
> > > > >   DateAndTime now asDate start ==> 2018-10-22T00:00:00+00:00
> > > > >
> > > > > So I think you are right. Given that a date is modeled as a duration, the
> > > > > start time of the date should align with the timezone of the DateAndTime
> > > > > from which it was created.
> > > > >
> > > > > The likely fix is to change DateAndTime>>midnight:
> > > > >
> > > > >   DateAndTime>>midnight
> > > > >       "Answer a DateAndTime starting at midnight of the same timezone offset as the receiver."
> > > > >       ^ self class basicNew
> > > > >               setJdn: self julianDayNumber
> > > > >               seconds: 0
> > > > >               nano: 0
> > > > >               offset: (Duration seconds: localOffsetSeconds)
> > > > >
> > > > > But fixing that triggers one other test failure so I need to sort that
> > > > > out before posting anything.
> > > > >
> > > > > Thanks for looking at this, much appreciated.
> > > > >
> > > >
> > > > I added a test to cover this case in Chronology-Tests in trunk, and a
> > > > fix in the UTCDateAndTime repository in Chronology-Core-dtl.30.
> > > >
> > > > Dave
> > > >
> > > >
> > >
> 


More information about the Squeak-dev mailing list