[squeak-dev] UTCDateAndTime updates for Chronology-Core

Levente Uzonyi leves at caesar.elte.hu
Wed Dec 26 00:52:44 UTC 2018


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


More information about the Squeak-dev mailing list