On Tue, 28 Jan 2003, Rick Measham wrote: > My argument against this is due to the multitude of time representations > that the module should be able to work with - without heaps of calculations. > Storing 'Months' is useful for Gregorian calendars, but is annoyingly > useless for decimal calendars. > > There are two time periods that do not change: Years (time the earth takes > to travel around the sun) and Days (time the earth take to spin one complete > revolution). I'd suggest that these the the two values that DateTime keeps > internally. The 'year' would be an integer delta from some Epoch (BC/1970) > and the 'day' would be a float representing how many days since the start of > the year value. > > This makes things just as easy for every calendar: > Decimal: Basically this format is already decimal > Gregorian: Date comes from the integer and the time from the following > fraction over 24. > Likewise any other calendar that is needed could be determined from these > two imovable periods.
Actually, Rata Die works quite well for converting to many other calendars, which is one of the reasons to use it. Unless somebody comes up with an amazingly convincing argument, I'm not going to switch to a different internal representation. The code we have works for _many_ possible uses. Even more importantly, it's tested and works right now. I want to release something within the next 4-5 weeks. Rewriting the internals would probably make that impossible. -dave /*======================= House Absolute Consulting www.houseabsolute.com =======================*/
