UTCDateAndTime updates for Chronology-Core

> I am putting five Chronology-Core updates in the inbox, to be moved to trunk
> some time soon. These are the updates to Chronology that change the internal
> representation of DateAndTime as described on http://wiki.squeak.org/squeak/6197,
> and with original development at http://www.squeaksource.com/UTCDateAndTime.
>
> When moved to trunk, the five MCZ versions will be loaded in sequence based
> on new update map entries, such that instances of DateAndTime will be
> converted in-place during the update process.
>
> Chris Muller has done a good deal of testing of these updates, with coverage
> including various Magma database scenarios that depend heavliy on DateAndTime
> (thank you Chris). Together we have resolved a number of important issues
> based on that testing, and are fairly confident now that it is safe to move
> the UTC updates for Chronology-Core to trunk.
>
> These changes are inherently risky because they modify the DateAndTime
> instances that are used trhoughout our source code and version control,
> and also because they are not easily reversed. I will be traveling for
> the holidays, so I do not want to move the updates to trunk until I can
> be around to respond to any problems. Most likely that will be December 28,
> but in the mean time the updates should stay in inbox.
>
> Once moved to trunk, there will be eight failing tests in Chronology-Tests.
> Each of these represents an issue that I think should be addressed in
> discussion on the squeak-dev list.
>
> Dave

> Hi Dave,
>
> I just ran into an issue related to DateAndTime >>
> #setJdn:seconds:nano:offset: while trying to parse a string. The problem
> is unrelated to parsing, so I made a minimal example:
>
> | now recreated |
> now := DateAndTime now.
> recreated := DateAndTime basicNew
> setJdn: now julianDayNumber
> seconds: now secondsSinceMidnight
> nano: now nanoSecond
> offset: now offset;
> yourself.
> self assert: now = recreated.
>
> The assertion will fail if your time zone is not UTC, because
> #setJdn:seconds:nano:localOffsetSeconds: will subtract the offset from the
> seconds before passing it to #microsecondsFromDay:seconds:nanosoffset:.
> And that method will subtract the offset again from the seconds part.
> So, the offset will be subtracted twice.
>
> Here is a similar, always reproducible example:
>
> | parsed recreated |
> parsed := '2010-07-20T22:31:29.924+02:00' asDateAndTime.
> recreated := DateAndTime basicNew
> setJdn: parsed julianDayNumber
> seconds: parsed secondsSinceMidnight
> nano: parsed nanoSecond
> offset: parsed offset;
> yourself.
> self assert: parsed = recreated.
>
> The value of parsed will be 2010-07-20T22:31:29.924+02:00, but recreated
> will be 2010-07-20T20:31:29.924+02:00 which is two hours off.
>
> If I remove the subtraction from #setJdn:seconds:nano:localOffsetSeconds:,
> the example will work, but there'll be a failing test case: TimeStampTest
> >>#testInstanceCreation, because #midnight will return a timestamp some
> hours off (unless your time zone is UTC). To fix that, I restored the
> original behavior of DateAndTime >> #midnight which passed 0 for seconds.
>
> The proposed changes are in the inbox. See Chronology-Core-ul.21.
>
>
> Levente
>
> On Thu, 20 Dec 2018, David T. Lewis wrote:
>
> >I am putting five Chronology-Core updates in the inbox, to be moved to
> >trunk
> >some time soon. These are the updates to Chronology that change the
> >internal
> >representation of DateAndTime as described on
> >http://wiki.squeak.org/squeak/6197,
> >and with original development at
> >http://www.squeaksource.com/UTCDateAndTime.
> >
> >When moved to trunk, the five MCZ versions will be loaded in sequence
> >based on new update map entries, such that instances of DateAndTime will
> >be converted in-place during the update process.
> >
> >Chris Muller has done a good deal of testing of these updates, with
> >coverage including various Magma database scenarios that depend heavliy on
> >DateAndTime (thank you Chris). Together we have resolved a number of
> >important issues based on that testing, and are fairly confident now that
> >it is safe to move the UTC updates for Chronology-Core to trunk.
> >
> >These changes are inherently risky because they modify the DateAndTime
> >instances that are used trhoughout our source code and version control,
> >and also because they are not easily reversed. I will be traveling for
> >the holidays, so I do not want to move the updates to trunk until I can
> >be around to respond to any problems. Most likely that will be December
> >28, but in the mean time the updates should stay in inbox.
> >
> >Once moved to trunk, there will be eight failing tests in
> >Chronology-Tests. Each of these represents an issue that I think should be
> >addressed in discussion on the squeak-dev list.
> >
> >Dave
>