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
- Re: Time::Local Darren Duncan
-
