All,
In the spirit of forward thinking and adaptability (and
internationalization), I believe a core Time/Date object should be
calendar agnostic and simply store some value that is easily
convertable to any date + time on any calendaring system. I say
forward thinking because this system will be forwards compatible with
calendaring systems that don't yet exist, and backwards compatible
with older calendars we haven't bothered to account for yet.
I believe that at its core said object should simply store a count of
rigorously defined time units relative to a rigorously defined epoch.
What the epoch is and what the time unit is will need to be
officially defined (eg, Jan 1, 2000; counting in fractions of
seconds). The object should not store anything other than this
single numerical value internally (smart caching of conversions
aside).
Save all human-desired representations to something that is computed
on request, such as using a getter method named after the desired
format; and setting would do the reverse. This can work with values
in any calendaring system.
With this system, date calculations and storage are trivially easy,
and Perl's built-in date/time function would simply return that
number or said object. All the complexity is in the getter/setter
methods that are specific to what details a user wants, such as the
day of week or an ISO formatted string. In fact, all of that actual
conversion stuff would be what modules are good for. Perl internally
just has to know about the one number.
-- Darren Duncan
- Re: Time::Local Darren Duncan
-
