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?

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