I think we discussed this a few months ago. The problem is "unsolvable" as it is now, IMHO, because all the chronology objects are based on "offset" representations (since an epoch), instead of a "field based" representation.
IMHO, the only way to have a proper "semantic" representation is to have field based date classes (like Java's Calendar object, not the best implementation though). Ej, which one of the followings is OK? '2012-02-29' asDate + 1 year "=> 2013-02-28" '2011-03-01' asDate + 1 year "=> 2012-02-29" '2011-03-01' asDate addMonths: 12 "=> 2012-03-01" Regards! El Mon Dec 01 2014 at 3:11:56 PM, Chris Cunningham <[email protected]> escribió: > Hi. > > I was working on a GenericYear that was intended to be used for > DateAndTime calculus - to be able to add and subtract an arbitrary number > of years. The class by itself would not know the days - it is an arbitrary > (generic) Year. > > It would only know the number of days when it is added (or subtracted) > from an actual date (or timespan). The idea was that it would have a very > specific and limited scope of responsibility. > > -cbc > > On Sat, Nov 22, 2014 at 3:03 AM, Hilaire <[email protected]> wrote: > >> I saw some discussion about Duration and year calculus in the list >> >> Given that it is impossible to determine the number of days in a year >> without the calendar years, should not 365.25 be used in place of 365 to >> minimize the error ? >> >> So it could look like: >> >> Duration class >> years: aNumber >> ^ self days: (aNumber * 365.25) truncated seconds: 0 >> >> >> Hilaire >> >> -- >> Dr. Geo - http://drgeo.eu >> iStoa - http://istoa.drgeo.eu >> >> >> >
