On Mon, 27 Jan 2003, John Peacock wrote: > 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.
So you want to greatly complicate the internals (and slow it down, I'd bet), for what? With the current implementation, you can get the effect of a day-sized granularity by creating dates like this: my $dt = DateTime->new( year => 1965, month => 10, day => 1, floating => 1 ); Setting the datetime as floating will mean there is no TZ or leap second calculation done, so as long as you just do math with the same high granularity, you're all set. Now, if someone wants to create a subclass or container class to _enforce_ the granularity, that's cool. But what exists right now will work quite well for this. I think the same goes for months and years. I wouldn't necessarily object to allowing this: my $dt = DateTime->new( year => 1965 ); Again, this could give the illusion of year-sized granularity. > On the other hand, if someone wants to know how many months there were between > May, 1776 and June, 1976, it seems less than helpful to convert to Rata Die or > seconds (or heavens be, attoseconds ;~) to store the data, then subtracting and > finally dividing repeatedly, just to get the answer 200*12 + 1. Except that it could greatly complicate all sorts of other things. > cases. The general case is someone who wants to calculate hours between > something, days until my birthday, years since Lincoln died. All of which are totally doable with the current code. -dave /*======================= House Absolute Consulting www.houseabsolute.com =======================*/
