[squeak-dev] UTCDateAndTime discussion + Q&A

Eliot Miranda eliot.miranda at gmail.com
Wed Nov 21 04:02:49 UTC 2018


Hi Chris,

On Fri, Oct 26, 2018 at 8:27 PM Chris Muller <ma.chris.m at gmail.com> 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.
>
> 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.
>

The simplicity of the large integer utcMicroseconds representation trumps
all the nonsense of breaking it down into sub components.  In any case the
32-bit VM is communicating time up to the image as 64-bit large integer
microseconds anyway.  Not decomposing gives much faster instantiation, and
very simple arithmetic (simply compare the utcMicroseconds).

Note that it would be trivial to extend the representation with the
decomposed elements, an d these could be nil initially and instantiated on
demand.  Forcing the large integer arithmetic to decompose on every
instantiation would kill any performance advantage one might expect to get
from using immediate instead of there large integer.  And of course in
64-bits, utcMicroseconds is an immediate anyway.


> > 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.
>
> 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...
>
>   - Chris
>
>
>  - Chris
>
> > Thanks,
> > Dave
> >
> >
> > >
> > >  - Chris
> > > 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
> > > >
> > > >
> > >
>
>

-- 
_,,,^..^,,,_
best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20181120/0b33ce60/attachment-0001.html>


More information about the Squeak-dev mailing list