I don't think that this has a practical impact, but I will mention it
in case I am overlooking something. The hash for a DateAndTime in a
64-bit image will be different from the hash for the same DateAndTime
in a 32-bit image, because the utcMicroseconds value in a 64-bit Spur
image is a SmallInteger, and in a 32-bit image it is a LargePositiveInteger.

This might be a concern if there is some scenario in which two images of
different word size are referring to the same hashed collection (possibly
via Magma or Gemstone?).

Dave


On Sat, Jan 05, 2019 at 03:30:23PM -0500, David T. Lewis wrote:
> Following the recent UTC updates to Chronology-Core, the hash for DateAndTime is:
> 
> DateAndTime>>hash
> 	^utcMicroseconds hash
> 
> This implies the need for a couple of follow up actions. I should have done
> "HashedCollection rehashAll" somewhere in the latest updates. This would be
> necessary for any hashed collections keyed by DateAndTime. I also need to
> update two unit tests that document the hashing, and that now fail.
> 
> Before I do anything about these, does anyone have any comments or concerns
> regarding how equality testing and hashing are being done for DateAndTime?
> 
> Thanks,
> Dave
>