Thank you Levente!

Dave

On Wed, Dec 26, 2018 at 01:52:44AM +0100, Levente Uzonyi wrote:
> 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
>