Hi. > Well... don't really like it. This means that there are three different > time origins for which the calendar time span gives the same result... > isn't it? > > 29 January 2007 + (1 year + 1 month) = 29 February 2008 > 30 January 2007 + (1 year + 1 month) = 29 February 2008 > 31 January 2007 + (1 year + 1 month) = 29 February 2008
Have you considered doing a survey of other Date/Time/Calendar implementations to find out how they solve this problem? For example, a lot of careful thought and research has gone into the Perl DateTime modules. http://search.cpan.org/dist/DateTime/lib/DateTime.pm#Adding_a_Duration_to_a_Datetime Very interesting. Thanks for the hint! :) It seems that the perl modules uses the same approach I was suggesting: "DateTime.pm always adds (or subtracts) days, then months, minutes, and then seconds and nanoseconds. If there are any boundary overflows, these are normalized at each step. For the days and months (the calendar) the local (not UTC) values are used. For minutes and seconds, the local values are used. This generally just works. This means that adding one month and one day to February 28, 2003 will produce the date April 1, 2003, not March 29, 2003." -- Jose E. Marchesi <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> GNU Spain http://es.gnu.org GNU Project http://www.gnu.org
