Anybody know who is currently maintaning this module? I hope it's not me.
-------- Original Message --------
Subject: Possible Bug in Date::ICal 1.72
Date: Thu, 3 Nov 2005 21:15:49 -0500 (EST)
From: Joshua Baer <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Rich Bowen:
My name is Joshua Baer, and I've been using your Date::ICal perl module to
produce RFC iCalendar formatted date-time fields. This module has been a big
help in speeding the development of my project, which produces an iCalendar
input file for the Oracle Calendar suite from an in-house calendar format.
The bug concerns the formatting of date-time iCal strings. When a Date::ICal
object is created which is supposed ends up representing midnight UTC on any
given date, the returned iCal string does not seem to comply with RFC 2445.
Example: (i'm in EST -5 GMT)
my $icalstrone = Date::ICal->new(year => 1981, month => 12, day => 1,
hour =>
19)->ical;
print $icalstrone;
yields:
19811202Z
---
my $icalstrtwo = Date::ICal->new(epoch => 1131321600)->ical;
print $icalstrtwo;
yields:
20051107Z
According to section 4.3.5 of RFC 2445 a properly formatted date-time
string for
midnight gmt utc would look like the following:
19811202T000000Z
20051107T000000Z
>From RFC 2445:
"
date-time = date "T" time
The text format is a concatenation of the "date", followed by the LATIN
CAPITAL
LETTER T character (US-ASCII decimal 84) time designator, followed by the
"time" format."
Furthermore, the "time" format expresses midnight with the string
'000000' not a
null string (Section 4.3.12), and the "date" format does not allow a
trailing
"Z" character. (Section 4.3.4) So, the Date::ICal->ical sub does not produce
output compliant with either "date-time", "date", or "time" formatted
fields as
they are defined in the RFC in this particular case.
I took a look at the source Date::ICal, ICal.pm and found that simple
fix will
bring the module into compliance. The following are lines 287 through 294 in
ICal.pm version 1.72:
if ( $self->hour || $self->min || $self->sec ) {
$ical =
sprintf( '%04d%02d%02dT%02d%02d%02dZ', $self->year,
$self->month,
$self->day, $self->hour, $self->minute, $self->second );
} else {
$ical =
sprintf( '%04d%02d%02dZ', $self->year, $self->month,
$self->day );
}
If the second sprintf statement (line 293) is changed to the following, the
problem should be fixed, at least if the desired output is in the
"date-time"
format.
sprintf( '%04d%02d%02dT000000Z', $self->year, $self->month,
$self->day );
Like I said before, using this module has been a pleasure, and if I had been
using any other Calendaring Suite than Oracle, there probably wouldn't have
been a problem. Unfortunately Oracle is extremely picky about which
iCalendar
formatted files it chooses to import, and which ones it chooses to reject
without any description whatsoever as to why the import failed. I suppose it
boils down to this: Oracle didn't like the non-compliant iCal output from
Date::iCal, and I just had the time of my life trying to debug hundreds
of iCal
records.
Thanks again for your work! Hopefully, this fix will save a couple of people
some time somewhere in the future. If you have any comments or
questions, I'm
available at [EMAIL PROTECTED]
Regards,
Joshua
--
Rich Bowen
[EMAIL PROTECTED]
