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.

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
> >
> >
>