calendar_ical isn't RFC compliant

FYI: I followed your instructions in #760284: template_preprocess_date_vcalendar needs to be changed to help calendar_ical be more RFC 2445 compliant that said to apply that patch before this one. The patches are partial dupes - both contain the same modifications to the Calendar module. Anyone trying to apply the patch in this thread after the one in #760284: template_preprocess_date_vcalendar needs to be changed to help calendar_ical be more RFC 2445 compliant will see errors. You'll probably want to separate the patches properly: one for code in the Date module, and one for Calendar.

I manually applied the patches, and determined they aren't getting my iCal feed completely compliant, but it's getting closer. I ran my .ics file through http://severinghaus.org/projects/icv/ and got the following error:

Error was: Error at line 12: Expected [61], read [58]

9:  	DTSTAMP:20100407T134759Z
10: 	DTSTART;TZID=America/Chicago;VALUE=DATE-TIME:20100407T090000
11: 	DTEND;TZID=America/Chicago;VALUE=DATE-TIME:20100407T200000
12: 	RRULE;RRULE:FREQ=WEEKLY;INTERVAL=1;UNTIL=20101231T060000Z;WKST=MO
13: 	URL;VALUE=URI:http://hmcpl.org/events/2009-09/bailey-cove-0
14: 	END:VEVENT
15: 	BEGIN:VEVENT 

Fewer errors than before, though! Marking 'needs work' to get the duplication resolved.

Aha! MUCH better. I tried the patches together, including the suggestion for RRULE change, and my feed finally validates. Google Calendar still isn't displaying the events, which I need to check on, but this is a promising start.

Grr. On the other hand, http://icalvalid.cloudapp.net vomits profusely. Lots of 'The time zone with the TZID 'America/Chicago' was not found.'

I applied your patch since I kept getting errors when importing the ics into google calendar ...still its not working and im stumped.

Took me a bit to fix my ics file because it was empty; now the data is in there but google no likey, man I was really hoping your patch would fix it... perhaps there is something wrong in my view though. Ive spend a bunch of time getting beautytips to work with my calendar and this little ics bugger is killing me! lol

Ive attached the ics and the view, what have I gone and screwed up? ...or is this a bug?
I have gone through all the TROUBLESHOOTING bits KarenS outlined... any help is greatly appreciated.

When importing the ics Google responds ..

Processed zero events.
Failed to import events: Unable to process your iCal/CSV file..

Im running...

Calendar  6.x-2.x-dev (2010-Apr-01)
Date 6.x-2.x-dev (2010-Apr-08)
Views 6.x-3.0-alpha3 (2010-Apr-08)

I ran it through that validator you posted in the first post and got this

Error:  	Error was: Error at line 9: [DTSTAMP] Unparseable date: "Z"
Cause: 	Caused by: [DTSTAMP] Unparseable date: "Z"

EDIT: Woops ... forgot to apply http://drupal.org/node/760284#comment-2828614

Ok well its working now .. I just have to get all that html markup out of it .. the validator is throwing "Illegal property" errors and google is displaying the markup instead of just the text.

woops I was using custom markup to make beautytips work in my other displays .. forgot to remove the [markup] when I did an override of the fields in the ical display... then just turned on strip html for the body and location fields.

All is well now .. I hope this gets committed since google wont work without it ... at least not for me.

will do .. I did notice one thing though ... seems thunderbird lightning doesnt like the ical file but thats better for another issue. This combo is the only thing that made google happy, thanks a ton!
Cheers!

When importing the ical I get the following

An error occurred when writing to the calendar username Calendar!
Error Code: MODIFICATION_FAILED

Im running...
Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4

However .. as I was writing this I tested something else .. I created another calendar inside lightning because I remembered that my main calendar in there was one connected to gmail. That was the prob because as soon as I used a diff cal it worked as expected! yay!

Im feeling the Drupal calendar love!

@skwashd - I'm seeing something strange that only appears when this patch is applied. The calendar popup is empty. I'm attaching a screenshot to give you an idea of what it looks like. The problem goes away as soon as I reverse the patch and clear the cache.

Caveat in the other direction: we do have some custom theming going on in node-event.tpl.php.

Is there a reason why the patch in comment 6 changes some, but not all, line endings in the feed to be CRLF (\r\n) instead of LF (\n)? Reading the spec says that CRLF is the correct line ending, but I can't see why this hasn't been changed everywhere.

After applying the patch, Apple's iCal app stopped displaying the content of my feeds. This was traced this to the mixed line endings - iCal will only display a feed if every line ends in CRLF, or if every line ends in LF. When I subsequently changed calendar-view-ical.tpl.php to print \r\n at the end of every line, the feed displayed in iCal again.

Every line from the initial BEGIN:VCALENDAR up to and including the PRODID: line, and then all BEGIN:VEVENT and END:VEVENT lines, and finally the END:VCALENDAR line.

Basically, all the lines that the patch doesn't change.

Thank you for the patch. Now it's working for me in Google calendar.

+1 Subscribing

So the linked issue on the Date issue queue says the patch is ready to be committed and this one says patch needs work, but the note says both need to go in together. If this one is not ready, that one is not ready.

I tried and failed to figure out what the patch actually is or whether it is working. #22 says 'it is working', but *what* is working? This issue is not clear at all.

By "it works" I assume Synex means the google calendar now correctly imports the ical feed. Before these two patches are applied, at least for me, the ical feed would not import all events into google calendar (usually stopping at the latest event created, but I didn't look into it that much.) As it turns out, the ical feed did not validate at http://severinghaus.org/projects/icv/. After both patches are applied, the feed validates at the previous website, and imports into google calendar without problem.

I can also confirm that the ical feed still loads correctly in evolution and sunbird. Also, it does brake the Calendar Popup module. Lastly, I believe this brakes the import to iCal. I'm not positive, because I tested it on an iPod Touch, but the import didn't work there.

@skwashd Thanks a lot. I can confirm that, at least on the ipod touch, the ical feed now imports correctly. Thanks.

Not sure. Two people isn't much of a test base. However, I will say that the ical feed now works flawlessly for me. It's great. Thanks again for the patch.

I've been testing this patch (and the related one for the Date module) to fix a problem with Outlook clients listing events an hour off. These patches did not solve the problem until I added the changes suggested in #757498: iCal events export incorrectly, switch to use UTC (Z) timezone for the Calendar module.

I'm attaching an updated version of the patch from this issue that integrates the changes from the other issue, including changing DTSTART and DTEND to using a UTC date value (like DTSTAMP). Also, I added a \r\n after the PRODID line to fix a validation error detected by http://icalvalid.cloudapp.net

Note: This patch show many lines from calendar-view-ical.tpl.php as changed because I ensured that the non-PHP lines uses \r\n for breaks.

- Patch applies to latest CSV code as per 14.10.2010 (Version 6.x-2)
- Also applied patch #760284: template_preprocess_date_vcalendar needs to be changed to help calendar_ical be more RFC 2445 compliant
- Checked line ending changes (CR LF) with RFC 5545. Care must be taken when editing .tpl files in future to preserve CR LF endings
- Checked UID change with RFC 5585, 3.8.4.7
- Patch does not deal with line folding as per RFC 5545, 3.1. As this is a "SHOULD" requirement it is not strictly necessary.

Tested with Thunderbird (lightning extension) and http://severinghaus.org/projects/icv/ but not with http://icalvalid.cloudapp.net as the validator is not reachable most of the time (at least for me, though other cloudapp.net sites work).
Recurring events have been tested only with one test case but this patch does not change handling of recurring events and therefore should be fine.

Possible caveat: Format of UID of events changed. When upgrading this might break existing ical feed imports (external site or application importing calendar ical feed) which rely on this. Recommended to delete imported events first (completely remove imported feed) and then import the ical feed from scratch.

Patch #30 includes #757498: iCal events export incorrectly, switch to use UTC (Z) timezone which can be marked duplicate when this patch is applied.

The popup no support multi-language. The popup link to the node id but this url path change to default language and no support navigation language.

View this post to solve: http://drupal.org/node/427388

After applying the patch I've seen the error and I think the error was in the patch

subscribe

Used patch #30 as with #31 along with #760284: template_preprocess_date_vcalendar needs to be changed to help calendar_ical be more RFC 2445 compliant #15.

Validating on http://icalvalid.cloudapp.net as well. Patch makes sense. Agree #31 RTBC.

I'm trying to figure out the reason behind this part in the patch:

-      $id = 'calendar:'. $item->{$view->base_field} .':'. $real_field .':'. $delta;
+      $id = 'calendar.'. $item->{$view->base_field} .'.'. $real_field .'.'. $delta . '@' . $domain;

The use of ':' as a splitter for the parts of the date is required for other things in the date module to work, so this change will break other things. Without any explanation for why it was changed, I can't address a way to fix this without breaking other things.

I'm going to apply the rest of this patch, leaving out the part that alters the splitter and let people sort out what still needs to be changed and why.

We also can't do the following:

$event['start']->setTimeZone(new DateTimeZone("UTC"));

That only works if you're using PHP 5.2 or higher and not everyone is. We have to use the wrapper function, date_set_timezone(), for compatibility with the older versions.

#35 I think is just following RECOMMENDED sections of the RFC. The UID can include ':' as it's a valid part of TEXT; but it could be problematic because parsers sometimes make invalid assumptions about the : separator similar (but not the same) as for example http://drupal.org/node/282521#comment-2950950 ;-)

Committed this much. If there are still problems please start a new issue with that information. This thread is getting pretty long and confusing.