On Sat, Mar 12, 2016 at 08:48:21PM +0100, Levente Uzonyi wrote:
Hi Dave,
I ran the tests and found that there are three types of failures.
- Some tests assume that the default offset is #localOffset. I don't
think it's correct, but that's how is it in Trunk.
There are 10 failing tests in my image. These are cases in which either I was uncertain how to handle the issue, or where I thought that the current behaviour in trunk may be wrong.
- Hashes have changed. This implies that HashedCollections containing
DateAndTime instances as key will have to be rehashed. In the base Trunk image there are appear to be no such HashedCollections, but not rehashing such collections will break images with custom packages in them after update.
I am not expert in this area at all. But part of the update process (in the MC postscripts) finds all instances of the old style DateAndTime, and becomes them into the new ones. Would the HashedCollections contianing DateAndTime instances as key still require rehash in that case?
Related to DateAndTime>>hash, I would also like to ask for guidance as to how DateAndTime>>= should be defined. Maybe this is an ANSI Smalltalk question, but I was not sure if we should be thinking of DateAndTime as a magnitude, such that two instances are equal if their utcMicroseconds are the same? Or are two instances equal if they have the same magnitude and also the same localOffsetSeconds?
I implemented the first approach (two instances are #= if they represent the same UTC time, regardless of timezone). There may be use cases where the other approach makes sense. But my thinking was that when comparing two instances of DateAndTime, they should not be considered the same unless they both represent the same point in time, hence UTC time regardless of the time zone in which the instance was created.
- Loss of resolution and strict monotonicity. In Trunk [DateAndTime now <
DateAndTime now] is always true. This is possible because DateAndTime has nanosecond resolution, but the source clock only has microsecond resolution, and our machines are so slow that it takes more than a nanosecond to execute the primitive. All these allow us to use the sub-microsecond part of the timestamp to create intermediate strictly monotonic values.
To be honest, I do not fully recall the rationale for this. One important case is that of the system clock being set back due to ntp synchronization. Fiddling with the nanoseconds number to make it appear as if the OS had reported an increase in time (when in fact it did not) seems questionable to me, but I know that it was done for some good reason. I do remember the discussions, so I should look back through the squeak-dev archives and find out the reason this was done.
Levente
Thanks very much for looking at this. I added you and Chris Muller as developers on the UTCDateAndTime repository on squeaksource.com in case you want to make any changes.
Much appreciated,
Dave