Hi David,

> On Jan 5, 2019, at 8:17 PM, David T. Lewis <lewis at mail.msen.com> wrote:
>
> 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 was taken care of for this kind of scenario in

Name: Kernel-eem.1198
Author: eem
Time: 24 November 2018, 1:44:47.526422 pm
UUID: 100137c4-2514-4b7f-9064-3dcdfe7d8cc9
Ancestors: Kernel-eem.1197

Redefine LargePositiveInteger hash for compatibility between 32-bit
and 64-bit systems.

>
> 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


_,,,^..^,,,_ (phone)

>
>> 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
>>
>