Grand Unified Theory of Date/Time modules

Front page | perl.datetime | Postings from May 2001

Grand Unified Theory of Date/Time modules

Thread Next

From:

Rich Bowen

Date:

May 5, 2001 10:26

Subject:

Grand Unified Theory of Date/Time modules

Message ID:

200105051725.f45HPXM27641@rhiannon.rcbowen.com

I'm hoping that there are enough people here that I'm not just talking to
myself.

This email discussed my grand goal for this mailing list, and for Perl
date/time manipulation in general. I think that this is a large-ish
undertaking, but I thought I'd tell you all what I'm thinking. I will also put
this on my web site (dates.rcbowen.com) RSN so that I can direct people to it
occasionally. (There's nothing there now, but hopefully I'll get to this soon.)

Complaints:

1) There are more than 50 Date or Time or Calendar modules on CPAN. Most of
them are unaware of all of the others, in the sense that they have no common
API or nice way to talk to one another.

2) Expressing times and dates in any reasonable way sucks. A lot. The person
who came up with a system in which we have 60 seconds, 60 minutes, 24 hours, 7
days, (28..31) days, and 12 months as our units needs to be beaten with a
yardstick.

3) There are dozens of non-Gregorian calendars, each of which is fascinating,
represents a wealth of cultural as well as mathematical depth, and is just as
valid and important as the Gregorian calendar. A few of these calendars are
represented by good Perl code. Most are not. Those that are are not represented
in any standard way.

General comments:

My goal is to have a standard way to write Perl date/time modules, so that they
can talk to one another, convert back and forth between calendars, and have a
semi-standard API.

In all of the various date formats I have looked at, each one has certain
flaws. Epoch time has a tiny window of usefulness (1970 - 2038). ISO requires
that you know a week number, and nobody thinks like that. Expressing the date
and the time as separate fields is too much work to convert back to something
useful. Julian dates are amazingly non-intuitive.

And then I encountered ICal format. It sucks less than any other format I've
encountered, in that it lets you store a date and a time in a single string in
a standard format that is easy to read, easy to parse, and covers all the stuff
you're going to need (date, time, timezone). And, it is sortable. (putting the
year first, then the month, then the day, allows you to sort dates correctly,
whereas day, month, year does not.)

Proposed solution.

Here's my proposal, and I really want your comments.

I want to have a base module (Date::Time, or perhaps just Date, or perhaps
Date::ICal) from which other date modules can inherit. It will know about the
ICal format, and will probably be able to convert to epoch time, but I'm not
sure if that is desirable or not.

Subclasses would have the following usefulness as requirements:

1) A Date::Foo object will *always* have an internal representaton as an ICal
string, no matter what you provide it when you create it.

2) It will have an ical method to return a correctly-formatted ical string.

3) It should be able to figure out its native format (Discordian, ISO,
whatever) from the ical string.

The consequence of this, if we're careful, is that we can create a
Date::Discordian object, for example, and then rebless it into the Date::Mayan
class, and it would just work:

my $disco = Date::Discordian->new( disco => '23 Chaos, YOLD 3177');
bless $disco, 'Date::Mayan';
print $disco->mayan;

This is because it has the ical property, and the Mayan package can reconstruct
the date, in Mayan format, based only on the ICal string.

I do not yet have example code that implements this concept, but I should have
Date::ICal, Date::ISO, and Date::Discordian displaying this behavior by the end
of the weekend, unless someone gives me some compelling reason why this is not
going to work.

-- 
Rich Bowen - rbowen@rcbowen.com
Have trouble remembering things?
http://www.idforgetmyhead.com/

Thread Next