Hi Dave,

I ran the tests and found that there are three types of failures.
1. Some tests assume that the default offset is #localOffset. I don't 
think it's correct, but that's how is it in Trunk.
2. 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.
3. 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.

Levente

On Sat, 12 Mar 2016, David T. Lewis wrote:

> Hi Levente,
>
> I had not checked the 64-bit image yet, thanks. I did notice from the
> 32-bit image that the DateAndTime>>= test shows that we might have an
> opportunity to improve #digitCompare: performance, or maybe think of
> a better way to do the #= implementation. Your 64-bit results show that
> it is not a problem for the 64-bit image (because we would be dealing
> with immediate small integers there).
>
> It's interesting to see that Spur is speeding up overall performance
> to the point that some primitives are starting to appear relatively
> slow in comparison. That is very nice problem to have :-)
>
> Dave
>
>
> On Sat, Mar 12, 2016 at 07:39:14PM +0100, Levente Uzonyi wrote:
>> Hi David,
>>
>> I just loaded the code into the latest 64-bit Spur image and VM.
>> Everything works so far, and the overall performance is better as well.
>> For those who care about performance, the speedups are
>>
>> #testNow->3.01.
>> #testEquals->1.83.
>> #testGreaterThan->1.86.
>> #testLessThan->1.92.
>> #testPrintString->0.85.
>> #testStringAsDateAndTime->1.75.
>>
>> So, #testPrintString is slighly slower, but everything else is
>> significanlty quicker.
>> I haven't reviewed the code yet, but I'll do.
>>
>> Levente
>>
>> On Sat, 12 Mar 2016, David T. Lewis wrote:
>>
>>> On Mon, Mar 07, 2016 at 12:21:38AM -0500, David T. Lewis wrote:
>>>> On Sun, May 24, 2015 at 12:36:02PM -0400, David T. Lewis wrote:
>>>>> UTCDateAndTime is a UTC based implementation of class DateAndTime with
>>>>> one instance variable representing the magnitude of the point in time,
>>>>> and another representing local time zone offset.
>>>>
>>>> I have updated the UTCDateAndTime package to make it loadable in the
>>>> latest
>>>> Squeak trunk and Spur.
>>>
>>> Has anyone looked at this yet? Any interest?
>>>
>>> Dave
>>>
>>>>
>>>> A new Monticello repository is at
>>>> http://www.squeaksource.com/UTCDateAndTime.
>>>> The home page (with a new SAR) is at http://wiki.squeak.org/squeak/6197.
>>>>
>>>> Starting with an updated trunk image, you can load UTCDateAndTime in two
>>>> ways:
>>>>
>>>> 1) Open the http://www.squeaksource.com/UTCDateAndTime repository, and
>>>> load
>>>> the MCZ files in sequence beginning with Chronology-Core-dtl.3.
>>>>
>>>> 2) In a preferences browser, in category 'updates' set the 'Update URL'
>>>> preference to 'http://www.squeaksource.com/UTCDateAndTime', and do
>>>> world -> help... -> update code from server.
>>>>
>>>> The main objective of UTCDateAndTime is to make DateAndTime conceptually
>>>> simpler, but a happy side effect is that it is also significantly faster
>>>> than the old implementation.
>>>>
>>>> Dave
>>>
>>>
>
>