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