Hi David, thanks for proceeding with caution, clearly, this is a core
framework upon which everyone's Squeak everything depends.  Some
questions:

>   DateAndTimeLeapTest>>testAsSeconds
>       - Discussion required. I claim that #asSeconds can only make sense
>         if it means elapsed seconds since the epoch. The prior implemention
>         and the test are both wrong.

Is there a context where the number of seconds since the epoch would
ever "make sense" except to the software which needs to compare it to
another result of #asSeconds?  Why does it matter what number we start
at?

>    DateAndTimeLeapTest>>testHash
>       - DateAndTime>>hash works differently now. Test should be either
>         updated or eliminated.
>
>    DateAndTimeTest>>testPrecision
>       - Discussion required. It is simply wrong to assume that two calls
>         to DateAndTime class>>now will always answer different values, and
>         it is even more wrong to fudge the clock accessors to make it appear
>         to be doing this when it is not. Yes I know that certain database
>         applications require distinct time stamps, but hacking the actual
>         system clock is not the right thing to do.
>
>   TimespanDoTest>>testDatesDo
>       - Need to change the test setUp method. The original intent is to test
>         date iteration using a time span begining with a UTC midnight. Test
>         will pass if the start time is constructed accordingly. Note however
>         that date iteration is suspect for durations starting at times other
>         than midnight in the local time zone, so additional tests may be needed.
>
>   TimespanDoTest>>testNext
>       - Same issue as testDatesDo, fix the setUp method and the test will pass,
>         but additional tests may be needed.

Can you clarify why the setUp method needs to be changed?  What is the
core difference between your framework and Chronology which makes this
test not work as-is?

I want to understand whether there are any compatibility issues to
worry about other than the internal format and the #hash calculation?

> The necessary #primitiveUtcWithOffset is present in all Cog/Spur/interpreter VMs.
> It is an optional named primitive (not numbered). If not present, the fallback
> code uses the Posix epoch for all new time values, resulting in a runnable image
> but with incorrect time stamps for new DateAndTime instances. Falling back to the
> original millisecond clock logic and primitives is possible, but it seemed to me
> to be an unnecessary complication so I got rid of it.

Wrong timestamps are a big deal.  It would be better to have an
unrunnable image than incorrect timestamps.  The former makes a
visible issue, the latter, an invisible, insidious one..

> Does anyone think that adding UTCDateAndTime to trunk is /not/ a good thing to do?

Until we're sure its a good idea, it's /not/ a good thing to do.  I
would like to encourage us all to take the due time to really
understand all the differences, and would ask someone to produce
documentation (on the wiki) which explains exactly what developers
need to do to, 1) update their application code, 2) update any
persistent instances from Chronology of DateAndTime, etc.

I think this will be a lot of work for me, but the reward will be
faster dates and times, which is a good thing, thanks for pushing on
this Dave.