> Chris, makeUTC already solved your both problems right?
> - it makes Date comparable, even when coming from DateAndTime of
> different time zone
> - it makes hash fast enough

Thanks Nicolas.  I actually have 37 senders of it in my financial app
which has become intolerable.  So I think makeUTC started out as a
quick-fix to address those issues and get me by until I could think
more about it.

Now I believe I have a good solution in the Inbox.

> I also notice that the offset used to create a DateAndTime is NOT
> taken into account when extracting the Date...
> The Date is always extracted with local time zone which is ... weird.

Agreed.  So international-systems that need Timezone-sensitive Dates
are all mixed up -- because it wants to always create them in the
local-offset of the running computer regardless of the timezone of the
source data.

I've changed that.  Now, Timespan offsets are cascaded forward from
their source -- whether that source be a DateAndTime, another
Timespan, or a user-specification (e.g., method argument).

When the offset is not specified, it will look to a new class-instance
variable:  'defaultOffset'.

The default value for defaultOffset must be Duration zero not just for
optimal hashing, but also so that more unsuspecting Squeakers besides
me and Jon don't get bitten so badly.  In my case, offset differences
in Date objects resulted in arithmetic testing to choose the wrong
logic paths.  There was no blow up, just corrupt data.  Ouch!

The legacy behavior, Dates that start at midnight of the local-offset
can be gotten by simply updating the defaultOffset thusly:

     Date localize

All tests pass except maybe not Timespan since its going to be purged.
 I'm going to chew on it for at least week -- if anyone wants to test
their app that'd be good too.