date_api does not parse broken EXDATE inputs(google calendar); date_api needs option to output broken ical for apple iCal

After applying this patch, the parser no longer hangs, but my exceptions don't show up at all. Anyone else experience this?

Here the exceptions aren't recognized. Even after deleting the parsed iCal Events and refreshing them.
We are using Drupal 6.14 and the latest dev versions of Date and Calendar.

According to the spec EXDATE is supposed to be followed by a colon. But Google may be sending incorrect format in order to satisfy apple's incorrect implementation. I wouldnt use google as a testcase for ical feeds.

EXDATE is *supposed* to look like this according to the spec (RFC2445: page 113 or so: http://www.ietf.org/rfc/rfc2445.txt)

EXDATE:TZID=America/Los_Angeles;20100112T160000,20100126T160000,20100119T160000,20100202T160000

But what Google sends out looks more like this:

RRULE:FREQ=WEEKLY;WKST=SU;UNTIL=20100217T000000Z;BYDAY=TU
EXDATE;TZID=America/Los_Angeles:20100112T160000
EXDATE;TZID=America/Los_Angeles:20100126T160000
EXDATE;TZID=America/Los_Angeles:20100119T160000
EXDATE;TZID=America/Los_Angeles:20100202T160000

Note that they get the colon/semicolon stuff right for their RRULE entry, but its wrong for the EXDATE.

Unfortuneately the spec is pretty unclear whether to ignore additional EXDATES, which the date_api_ical.inc is properly doing.

I think date_api_ical.inc should definitely handle parsing both the correct implementation, as well as major implementations. (I have written my own patch to properly handle google's perception of repeated exclusion dates [note that the current implementation drops the Timezone of the exclusion dates]).

Anyhow, the *output* of this will "fix" sending out ical data to Apple ical calendars, but likely break any other standards compliant parsers. perhaps there should be an option to output different ical variants?

If there is a "field" after the EXDATE (like TZID=America/Los_Angeles)

Right. A can of worms.

I wrote the parser to follow the spec, which Google is not. Not only the colon but also the method of supplying multiple EXDATEs. According to the spec, it should look like this, a comma-separated list:

Example: The following is an example of this property:

     EXDATE:19960402T010000Z,19960403T010000Z,19960404T010000Z

As you see above, Google is spitting out each one as a separate element.

So the trick is to not rewrite the parser to match Google's broken implementation, but to write a parser that is smart enough to fix the brokenness without breaking code that is structured correctly.

I'm not sure we have a patch that does that yet.

Perhaps this should be split into two issues? Re-titling to reflect both problems.

Unfortunately the D6 version of this module is no longer supported, but we appreciate the time you put into this. If this problem is relevant for D7 too, please reopen the issue. Thanks.