Actually, there was a big oversight in my last message. It does not handle approximate or relative dates, such as when you don't know the details.

My previous proposal should be restricted specifically to the situations where you know the date/time to a high precision, to the second. So my previous proposal would still work for general tasks where the date/time you are storing in the object is generated by a clock, such as the computer's clock or a network time server etc, and is perfectly appropriate for what Perl's built-in "get current date/time" returns.

I should also clarify that when I say "rigorously defined epoch", that also specifies a location (such as, "Jan 1, 2000, at Greenwich (sp?)"). Any mess related to time zones would be accounted for only during any calendar conversion used for storage or retrieval.

For the other side, where the dates are imprecise, it actually would be useful to store them internally in calendar specific and human terms, basically matching whatever the source was. For example, you would store a date/time like "early May of 1743" this way; if all you know is that the date was in "early May", then what you're storing is fully accurate. Shoe-horning this into a specific day etc just for storage makes the data less accurate because someone reading the storage value presumes we knew for sure it was that day etc when in fact we didn't. Another example of an imprecise and relative date is "in the 4th year of Xerxes reign". If you didn't know when on our calendar that Xerxes ruled, you can't exactly convert this to a Gregorian calendar; you must store it in the terms that I mentioned for highest accuracy.

Now of course, for such imprecise things, the simplest storage method is to just use a character string. Where it gets more complicated is if you want to do math or calculations with this imprecise info; that's one place that date/time such modules would really be useful and have their work cut for them.

BTW, my main programming project (unreleased) is a genealogy/history/anything database type application, of an unprecedented focus and feature set, so I've thought a lot about these sorts of issues for being the most accurate and trustworthy possible.

-- Darren Duncan

Reply via email to