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