>> Remember yesterday you mentioned how having another Date class to
>> support TZ's could be confusing?  I agree!  Well, with Chronology, we
>> don't need two, because it implements a Date as a Timespan with a
>> duration of 1-day.  So this brilliantly supports both families of
>> use-cases simultaneously; the ones that want to do *scheduling* (with
>> TZ's) and the ones that simply want Date positions (or Hour positions
>> or Minute positions), that compare quickly and successfully with other
>> Date/Hour/Minute positions (because Chronology implements those with
>> underlying offset of 0:00:00).
>
> An offset of 0 in Chronology means that point in time is given in UTC. It does not mean there is no timezone.

Okay, but according to your change of Timespan>>#=  yesterday:

         "defaultOffset means ignore time zone"

Bingo!

>> When I'm dealing with Dates as positions, I ignore the underlying
>> DateAndTime and its TimeZone.  It's just for Chronology's
>> implementation, which I don't need or want to concern myself with.

... and that is the point I tried to express, above (but was ignored).
For Dates, the underlying implementation can and should be
conveniently ignored just like encapsulation lets us do everywhere we
want to with OO.

>>> It may very well be that we do want a Date without a Timezone. That’s why we need a rewrite of Chronology that allows that, and makes it explicit.
>>
>> Timespan class>>#current explicitly specifies the #defaultOffset,
>> which has a detailed comment.
>
> Yes, that’s why I changed the equality check in Timespan to check for the defaultOffset and in that case ignore the time zone. I’ll do the same for magnitude comparison, which makes all tests green again. It’s the best we can do for now I think.

Not being able to run Squeak in the context of a remote timezone is a
huge downgrade.  I see no reason we should compromise, downgrade, or
break anything.   :(