>> In addition, the creation of Dates with Date today must not have a TZ
>> specified.  Your change broke that and I've added a test.
>
> This is a very arbitrary requirement you are imposing there. There is no DateAndTime without timezone. A zero offset does not mean “no timezone” but it means “UTC”.

There is no DateAndTime without a TZ, but there are *Dates* without
TZ's.  There have been several discussions on the Squeak and Pharo
lists about this, it is not an arbitrary requirement in the least.
People want Dates without timezones more often than they want them
with.

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

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.

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