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 |
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 |
Free forum by Nabble | Edit this page |