[squeak-dev] UTCDateAndTime discussion + Q&A

Chris Cunningham cunningham.cb at gmail.com
Tue Nov 20 19:22:49 UTC 2018


HI.


On Fri, Oct 26, 2018 at 4:39 PM David T. Lewis <lewis at mail.msen.com> wrote:

> On Fri, Oct 26, 2018 at 03:54:28PM -0500, Chris Muller wrote:
> > Hi Dave, I took a look at Chronology-Core-dtl.30, it looks like a good
> change.
> >
> > Now we just need something to obtain a canonical date from
> > DateAndTime's similar to Chronology's #beCanonical.  BUT, given the
> > confusion we've had about #asDate in the past, what if we changed
> > #asDate to do the "expected" behavior -- answer the canonical version
> > --, and added, say, #asLocalDate to preserve the not-so-common
> > version?
>
> Hi Chris,
>
> That sounds reasonable enough to me, although I would defer to you and
> others as to what is the preferred default because I really don't have
> any applications that would be impacted one way or the other.
>
> I think I would prefer to have DateAndTime now asDate (the asDate part)
return a canonical date - one with the starting time having no offset at
all.  While I have had cases to use the local date, they are actually rare
and far between. On the other hand, wanting a canonical date is very
common, and apparently expected by most other users.
I definitely approve of adding a #asLocalDate for those cases where I want
the local date.

Along these lines, I think we should make the default #asMonth, #asYear,
#asWeek also return canonical instances.  These make even less sense to
have in the 'local' time.
That said, the default Duration probably doesn't deserve the same canonical
treatment - if I want 2-1/2 hours starting now, I definitely want it in the
same timezone!

-cbc

ps - I strongly vote for integrating UTCDateAndTime into Trunk, having just
been bitten by the daylight savings again - my long running image never
switched over to the new offsets, since that apparently only happens when
you restart the image.  So, wrong offset for a good week before I noticed.


> 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
> 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.
>
> 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
> > >
> > >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20181120/b6eb2dab/attachment.html>


More information about the Squeak-dev mailing list