Hi, I'm trying to convert iCal files into RDF statements, and I want to be sure the dates come out right. I'm sure you're aware Data::ICal doesn't help much on that score. My roughed-in plan goes something like this:
* Goal: find appropriate offsets for DATE-TIME values in the iCal format for the purpose of converting them xsd:dateTime literals (via DateTime objects). * Problem: timestamps not specified in UTC or explicitly local are linked to VTIMEZONE objects within the iCal document to resolve their time zone offsets. * Observation: while some of these objects are congruent with the Olson naming scheme, this is is ostensibly a convention and by no means reliable (notably in Outlook, which is one of the targets). * Finding existing DateTime::TimeZone/s based on either TZID or VTIMEZONE content is ideal, * Constructing provisional DateTime::TimeZone objects from the VTIMEZONE content and keying them by TZID is probably sufficient. Of these, the easiest scenario is when the TZID is the same as an Olson key. Constructing a time zone from scratch using DateTime::TimeZone->_init(...) seems manageable but is undocumented (though a completely separate subclass may be reasonable). The ugliest solution turns out to be to find existing DateTime::TimeZone classes based on data, since it seems to go against the grain of the design of the package. So I guess my first question is am I overlooking something that Just Does It™? Second question is if I was to hand-roll my own DateTime::TimeZone objects, is there anything you can tell me about a strategy for doing that? Do DateTime etc objects stick reliably to the DateTime::TimeZone interface such that's it's reasonable to create a subclass? Finally, a meta-question: would it be useful to spin this out as a stand-alone module (e.g. DateTime::TimeZone::Constructed)? Thanks, -- Dorian Taylor http://doriantaylor.com/
