On 28/1/03 1:20 pm, John Peacock at [EMAIL PROTECTED] spake thus: > Hence, it would seem to me to make the most sense to store the basic DateTime > object as an array of (possibly undefined) periods: years, months, days, > hours, > minutes, seconds, etc. By doing it this way, instead of some sort of days > since > some epoch, any date or in fact any time differences are trivial. And by > storing the data in an array from most to least significant values, it would > be > possible to ignore meaningless distinctions where appropriate.
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. Just my $0.02 Cheers! Rick Measham P.S. Storing Years/Days also make the module transportable .. every planet in the universe has a day and a year and thus could use the module without huge changes :) -------------------------------------------------------- There are 10 kinds of people: those that understand binary, and those that don't. -------------------------------------------------------- The day Microsoft makes something that doesn't suck is the day they start selling vacuum cleaners --------------------------------------------------------
