> If we can assume that the current Squeak implementation of Date as
> a duration makes sense for a class named "Day" and that the prior
> implementation of Date as a magnitude makes sense for a class named
> "Date", then a possible way forward would be (in someone's local image,
> not yet in trunk):
>
> - Rename class Date as Day
> - Copy the Date tests to a new class for the Day tests.
> - Make sure that the tests for Day are working.
> - Load an old version of Date from the most recent Squeak version that had Date as a magnitude.
> - Make the unit tests work for Date.

Hi Dave,

I appreciate your point about the semantics of the word "Date" vs.
"Day" but since DateAndTime is also part of Chronology, I hope you
don't intend to rename it to "DayAndTime" and make it work with Days..
:)

DateAndTime has #asHour, #asDate, #asMonth, #asYear -- each one
returning an instance of the appropriate Timespan subclass.  This
proposal would interject a totally orthogonal "exception" into the API
of Chronology.  Your Magnitude version of Date would have a different
API like #isTimespan, for example.  So, it would break many
applications not just from the format change, but their application
logic too.  That's too big a cost.

I worked a lot with Brent for several years, I know his style is to
make terse and elegant API's.  Chronology provides us with a robust
interoperation of inputs with its outputs.  I happen to know the
compactness of the API was a deliberate part of his legacy creation.
We should respect that.

> I was really just trying to ask for a good class comment.

I really do think this is the best way to do this clarification.  Did
you notice that Bert already updated the class comment of Timespan to
mention the dual capability?  So, I think simply removing that old
stuff from Date's comment is simple and effective solution without
breaking legacy apps.