I was looking to use this module in processing ICal files however I
found issues in using it because it isn't clear to me how it was
intended to be properly used given the ICal specification. Any way I
look at using it it seems like duplicate effort will happen in my
code and it if I'm going to safely use it for all RFC compliant cases.
According to the RFC2445 specification all the following I believe
are considered valid DTSTART lines that could be found in a RFC2445
compliant file.
1) DTSTART:19980118T230000
2) DTSTART:19980118T073000Z
3) DTSTART;TZID=US-Eastern:19980119T020000
And I believe if we pass DateTime::Format::ICal anything from the
above past either what ever comes first ":" or ";" for the above
cases we are good. However I sort of find it a little odd that we
would pass what the RFC calls parameters along with the value.
But we also can have things like this.
4) DTSTART;VALUE=DATE:20051210
5) DTSTART;VALUE=DATE-TIME:19980118T073000Z
6) DTSTART;VALUE=DATE-TIME;TZID=US-Eastern:19980119T020000
7) DTSTART;VALUE=DATE-TIME;TZID=US-Eastern;X-MYPARAM=hello:
19980119T020000
8) DTSTART;VALUE=DATE-TIME;TZID=US-Eastern;X-MYPARAM="My Hello to
you":19980119T020000
As best I can tell DateTime::Format::ICal will not process any of the
cases 4-8 if I just pass it everything after the first ";".
If all DateTime::Format::ICal wants is the actual value and possibly
the time zone parameter then it might make since to have the two
values that the parser accepts parse_datetime(<value>) parse_datetime
(<value>,<timezone>) if the intent is for parse_datetime to accept
any of the above cases as <value> then it should support all of them.
It just seems like extra work for me to decompose the whole string
and then in one case have to put part of it back together if a
timezone was included just so DateTime::Format::ICal can then again
decompose it all over again. So to me I would rather see datetime
either support two possible parameters or have it support all
possible forms with the acceptance that it would never do anything
with the "X-" properties but would ignore them if found and still
process what it understands if it is all RFC compliant. Perhaps some
hook for adding a custom module addon for processing X- hooks if
needed would be nice but I'm not to worried about that.
I haven't looked at all the other RFC properties that are dates to
see if they are all identical to DTSTART so it may be possible that a
bunch of other reasonable things are possible for other date based
properties.
I'm not actually a member of this list so if you have any questions
for me please send me a e-mail directly.
Regards
Matthew
