iCal & Exchange 2007

[jberanek]

I am encountering an interesting problem with iCal and Outlook 2010/Exchange 2007 for recurring appointments. When I receive a recurring event .ics, Outlook shows that the time is several hours off. I have come to realize that this time correlates exactly to the UTC-OFFSET of my locale. This problem does not occur with single events, and it may be related to our implementation of Exchange 2007, which is run by a different department.

Looking at functions_ical.inc, I noticed the comment on line 196 about using TZID and the VTIMEZONE component, which is "form 3" according to the iCalendar Spec (http://tools.ietf.org/html/rfc2445#section-4.3.5). Currently, MRBS is using Form 2 of the spec, and seems to work perfectly with Google Calendar for both recurring and single entries.

I decided to experiment with form 3 and this has resolved the issue for me. Exchange now properly recognizes the time. I had to add the following code to functions_ical.inc (note: line numbers are based on the original file and do not take any additional lines mentioned below into account)

Line 200: (create_ical_event()) Changed: $results[] = "DTSTART:" . gmdate(RFC5545_FORMAT . '\Z', $data['start_time']); $results[] = "DTEND:" . gmdate(RFC5545_FORMAT . '\Z', $data['end_time']); to: global $timezone; $results[] = "DTSTART;TZID=".$timezone.":".date(RFC5545_FORMAT, $data['start_time']); $results[] = "DTEND;TZID=".$timezone.":".date(RFC5545_FORMAT, $data['end_time']);

Line 342: (create_icalendar()) Added: global $timezone;//get MRBS timezone $summer_date = "20110609121520"; //Random date in the summer to calc DST $winter_date = "20111209121520"; //same as above for winter DST $offsetto = date("O",date($winter_date)); //get Non DST offset $offsetfrom = date("O",date($summer_date)); //get DST offset

$results[] = "BEGIN:VTIMEZONE";    
$results[] = "TZID:".$timezone;
$results[] = "X-LIC-LOCATION:".$timezone;
$results[] = "BEGIN:DAYLIGHT";
$results[] = "TZOFFSETFROM:".$offsetto;
$results[] = "TZOFFSETTO:".$offsetfrom;
$results[] = "TZNAME:".date("T",date($summer_date));
$results[] = "DTSTART:19700308T020000"; 
$results[] = "RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=2SU"; 
$results[] = "END:DAYLIGHT";
$results[] = "BEGIN:STANDARD";
$results[] = "TZOFFSETFROM:".$offsetfrom;
$results[] = "TZOFFSETTO:".$offsetto;
$results[] = "TZNAME:".date("T",date($winter_date));
$results[] = "DTSTART:19700308T020000";
$results[] = "RRULE:FREQ=YEARLY;BYMONTH=11;BYDAY=1SU"; 
$results[] = "END:STANDARD";
$results[] = "END:VTIMEZONE";

Hope this helps,

-Shane

Reported by: *anonymous

Original Ticket: mrbs/bugs/220

[jberanek]

Thanks for this. It would be interesting to know whether Outlook is paying attention to your timezone definition or whether it's just treating the time information as a local time? In other words, what happens if you change the offset in the timezone definition?

While providing a timezone definition may work for you, it's going to be a bit of a pain if we have to provide timezone definitions for all possible timezones. I'll do some research and see if there's another solution.

Campbell

Original comment by: campbell-m

[jberanek]

Outlook (2010) seems to treat the UTC formatted time (for recurring appointments only) incorrectly as a local time.

I my case, changing the VTIMEZONE data to offset -0400 in an ics file works as expected. Outlook lets me know that the "scheduler" set the appointment for Atlantic Time (Canada) and adjusts the event for my time appropriately.

I can imagine the pain, which is why the way I think you implemented it (using UTC) is the better alternative. I just wish that Microsoft behaved....

-Shane

Original comment by: *anonymous

[jberanek]

I just wonder whether the order of the properties is important to Outlook, although as far as I can see in the spec it should be irrelevant. It's strange that Outlook copes OK with single events, but not recurring events. So I wonder whether putting the RRULE property after the DTSTART and DTEND properties, instead of before, makes a difference. I'm going to be busy on other things for the next few days, but will try it when I can get back to MRBS, but if you get a chance to try it yourself I'd be interested to know the results.

Campbell

Original comment by: campbell-m

[jberanek]

Campbell,

You're right, the spec does say that the order of the elements is irrelevant. I played around with the order in the following ways:

1.) RRULE is after DTSTART and DTEND (Booking(no Change).ics) 2.) RRULE is before DTSTART and DTEND (Booking(orderChange).ics) 3.) RRULE is after DTSRTAT and before DTEND (Booking(orderChange 2).ics)

2 Above failed to import as a valid meeting into Outlook, while #1 and #3 work properly for single events in each case, but do not work for recurring appointments (tested with weekly, Mon, Wed, Fri).

Unfortunately, it seems that it only works properly for recurring appointments when there is a VTIMEZOME componant, and the DTSTART field has the TZID specified along with a "local" time string that follows.

I have attached all three .ics files for your convenience, as well as a fourth file with the VTIMEZONE section which works for me. Here is a link to the spec where I discovered the different "forms" (http://tools.ietf.org/html/rfc2445#section-4.3.5)

Thanks,

-Shane

Original comment by: *anonymous

[jberanek]

Timezone Output

Original comment by: *anonymous

Attachments: https://sourceforge.net/p/mrbs/bugs/_discuss/thread/b3fa6f05/ab9b/attachment/Booking%20%28VTIMEZONE%29.ics

[jberanek]

No Change to Code Version

Original comment by: *anonymous

Attachments: https://sourceforge.net/p/mrbs/bugs/_discuss/thread/b3fa6f05/75f3/attachment/Booking%28no%20Change%29.ics

[jberanek]

This one corresponds to item 3 in comment

Original comment by: *anonymous

Attachments: https://sourceforge.net/p/mrbs/bugs/_discuss/thread/b3fa6f05/abfa/attachment/Booking%28orderChange%202%29.ics

[jberanek]

This one corresponds to item 2 in comment

Original comment by: *anonymous

Attachments: https://sourceforge.net/p/mrbs/bugs/_discuss/thread/b3fa6f05/1bf2/attachment/Booking%28orderChange%29.ics

[jberanek]

Thanks for trying. Oh well, guess I'll have to switch to using VTIMEZONE ...

Campbell

Original comment by: campbell-m

[jberanek]

I think I understand a little bit more about this now.

Outlook/Exchange is actually implementing RFC 2445 (the predecessor to RFC 5545) correctly. RFC 2445 under Section 4.8.5.4 that:

"When used with a recurrence rule, the "DTSTART" and "DTEND" properties MUST be specified in local time and the appropriate set of "VTIMEZONE" calendar components MUST be included."

However RFC 2445 has now been superseded by RFC 5545, which removes this requirement. Specifically, in Appendix A it states that:

"The "DTSTART" and "DTEND" properties are no longer required to be specified as date with local time and time zone reference when used with a recurrence rule."

So Microsoft is actually implementing RFC 2445 correctly. It's just that RFC 2445 has now been superseded by RFC 5545. This means that we really need to be able to create VTIMEZONE components in order to be able to support older calendar apps written to RFC 2445. However I haven't been able to find a good way of generating VTIMEZONE components, in particular the RRULE for when DST transitions happen. The best way I can come up with at the moment is to use the PHP DateTimeZone::getTransitions() method to get the DST transitions and then to try and fit a rule to the transitions. But I'm sure (I'd hope) that there must be a better way ...

Sio I'm no nearer a solution, but think I understand what's going on!

Campbell

Original comment by: campbell-m

[jberanek]

One way of getting the VTIMEZONE components is from http://tzurl.org/

Campbell

Original comment by: campbell-m

[jberanek]

I've implemented a fix in Rev 1856. If you get a chance to confirm that this works on your system that would be great.

Campbell

Original comment by: campbell-m

[jberanek]

Updated further in Rev 1862.

Campbell

Original comment by: campbell-m

[jberanek]

• status: open --> closed
• assigned_to: Campbell Morrison
• milestone: --> Future_Requests

Original comment by: jberanek