Front page | perl.datetime |
Postings from May 2001
Re: Grand Unified Theory of Date/Time modules
Thread Previous
|
Thread Next
From:
srl
Date:
May 5, 2001 11:49
Subject:
Re: Grand Unified Theory of Date/Time modules
Message ID:
Pine.LNX.4.21.0105051409240.28660-100000@grendel.csc.smith.edu
On 5 May 2001, Rich Bowen wrote:
> 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.
Getting this fixed would be a lovely thing IMO.
> 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.)
I should point out that not everyone knows what ICal is.
It's RFC2445, the IETF standard protocol for calendaring and
scheduling. Net::ICal, which is currently in alpha releases,
speaks it. The Reefknot team is working on making good iCal support
happen in Perl. So we have a vested interest in seeing everything be
able to speak iCalendar; it will mean that more date/time modules
can be used with the shared calendaring tools we're building.
> 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.
Tobias Brox (TOBIX on CPAN) has a module skeleton out for
Date::Time. Maybe we could get him in here to talk about this.
> 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.
Hm. I'm not so sure about this, but I guess it's the only way to
accomplish 2> and 3> elegantly.
> 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:
And that would be unspeakably cool.
> 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.
I can't think of any such reasons.
srl
--
Shane R. Landrum slandrum@cs.smith.edu
we generate our own light to compensate for the lack of light from above -AD
GPG public key: http://cs.smith.edu/~slandrum/srl_pgpkey.txt
Thread Previous
|
Thread Next