On Fri, Mar 06, 2015 at 10:31:16PM -0800, Chris Cunningham wrote:
> Hi.
> 
> Sorry for the excessively long delay in fixing the bugs in this package.
> 
> In the inbox are three packages that make a complete update with date/time
> arithmetic:
> Kernel-cbc.910
> Collections-cbc.604
> KernelTests-cbc.291
> 
> The first two extend the existing date arithmetic such as Date today + 3
> days to include months and years as well.  Adding months (or subtracting
> months) make it be the number of months you add/subtract off, nearest the
> date of the first month as you can get.  So, February 28 + 1 month gives
> March 28; January 31 + 1 month gives February 28th (or 29 in a leap year).
> Similarly with year.
> In addition, the durations can be chained together, such as 1 month + 1
> year + 1 month, and then add this to a date (or dateAndTime).
> Finally, these are covered by test, including additional tests for doing
> date arithmetic (which previously did not exist).
> 
> Thanks,
> cbc

In earlier discussion of this, I think that people were generally positive
and thought it was a good idea. The added tests are definitely welcome too.

I do have a concern about the overall approach, and would like to hear
what others think. The new classes GenericDuration, GenericMonth, and
GenericYear are helper classes to support Gregorian calendar arithmetic.
Maybe it is just the class names that are bothering me, but this does
not seem like a "generic" thing.

I think that Java does a good job with its approach to calendar arithmetic.
There is an abstract Calendar class that "provides methods for converting
between a specific instant in time and a set of calendar fields such as
YEAR, MONTH, DAY_OF_MONTH, HOUR, and so on". The concrete implementation
most commonly used is class GregorianCalendar, which implements the kinds
of month, day and year calculations that we expect in Squeak.

In Squeak, we do not do a very good job (mostly for historical reasons)
of conceptually representing the difference between "a specific instant
in time" versus calendar and time zone presentation of that instant in
time. I don't know that added GenericDuration, GenericMonth, and
GenericYear make the problem any worse, but somehow it does not quite
feel right to me. Maybe it's just the class names?

I do think that Chris' packages are useful and convenient, so I hope
this does not come across as negative. It's just that when I read the
Java class documention, I come away with a better understanding of the
time and calendar concepts. When I look at the same things in Squeak,
I go away confused.

Dave