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
* Goal: find appropriate offsets for DATE-TIME values in the iCal
format for the purpose of converting them xsd:dateTime literals (via
* 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
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)?