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 <cunningham.cb@gmail.com> 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 <hilaire@drgeo.eu> 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