Dave Rolsky wrote:
I think that we should treat this as 3 + undef, since the "date" in question did not specify a day, only a month. So I would either return july 1974 (plus a warning) or throw an error ("Date does not have enough precision").You'll probably need to write your own module around DateTime.pm. For example, how do you handle adding 3 days to july 1974? How about 31 days?
This leads me nicely into what I've been thinking about. There was a discussion on this list about "temporal granularity" back in May 2001:
http:[EMAIL PROTECTED]/msg00045.html
which was mostly part of the original "What's our Name Space???" discussion. However, I find the concept itself very appealing for the present discussion of storage methods.
For example, if a geologist wants to use a DateTime object, he is only interested in years (and millions of them) and not what time it was (apologies to Bishop Usher). Similarly, someone writing a business calendar (how many days until I get paid for this job) is not going to care about attoseconds. Someone writing a realtime event program may only want to know how many seconds have elapsed since some previous time. Each user will have a different granularity of interest.
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.
I hear the gnashing of teeth out there already: "But what about leap seconds?" and "What about different TZ calculations?" This doesn't preclude handling those appropriately, when called for. If someone cares about how many seconds there are between two DateTime objects, and both objects are defined with seconds, then both the TZ and leap seconds come into play. If only one object has seconds, my gut says give an answer with a supressable warning that accuracy has been lost; if neither are precise enough, die screaming.
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.
Sure, there are lots of useful formulas to go from Rata Die to other date formats; store that too, as a cached value. Or just convert to that when going to other formats (my preferred method). Those are going to be the exceptional cases. The general case is someone who wants to calculate hours between something, days until my birthday, years since Lincoln died.
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4720 Boston Way
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5747
