Writing ICS files for multiple clients, including

Question

I need to write a script for publishing .ICS files. I've read that it's difficult to do this right, either because some calendar clients are buggy (lots of people claim Google Calendar is extremely buggy especially regarding time zones) or because developers aren't following the spec properly. I only need to do this for North America but I do have to account for DST (keeping in mind places like Arizona, parts of which observe DST and parts of which don't).

Can anyone answer these questions?

1. When specifying a start and end time for an event, should this be provided always in the user's local time or can I send it as a UTC time and leave it to the client to figure it out?
2. Do I have to take any extra steps to account for DST at the user's location?
3. Do I have to take any extra steps to account for Google?

Any other tips?

Answer 1

Times in ICS files can either be floating or fixed.

A floating datetime contains no reference to UTC or a time zone - the time should be the time the ATTENDEE should arrive for the meeting in his/her local timezone. This could result in different attendees having the meeting at different times, so should be used with caution (or never!).

A fixed time is a better way to go. The format changes depending on whether the meeting is taking place in UTC or not.

For UTC meetings, use Z to specify UTC:

19980119T070000Z

Where the meeting is not in UTC, use the TZID format to specify a timezone. The following represents 2am New York time:

TZID=America/New_York:19980119T020000

Note: the TZID format should not be used for UTC times.

All this is specified in RFC 5545, Sections 3.2.19 and 3.3.4

The RFC has the following to say about DST - read into it what you will!

If, based on the definition of the referenced time zone, the local time described occurs more than once (when changing from daylight to standard time), the DATE-TIME value refers to the first occurrence of the referenced time. Thus, TZID=America/ New_York:20071104T013000 indicates November 4, 2007 at 1:30 A.M. EDT (UTC-04:00). If the local time described does not occur (when changing from standard to daylight time), the DATE-TIME value is interpreted using the UTC offset before the gap in local times. Thus, TZID=America/New_York:20070311T023000 indicates March 11, 2007 at 3:30 A.M. EDT (UTC-04:00), one hour after 1:30 A.M. EST (UTC-05:00).

Answer 2

You've heard right - it is not easy. Easy to offer very basic ics support, not that easy to offer complete support to what an ics provider may output; especially wrt recurrences, exceptions, modifications and yes timezones.

I have been working on my ics publisher for a long long time, it is pretty stable now. I have made some notes along the way.

See http://icalevents.com/category/notes/. Also the timezone tag on my site you may find helpful.

In particular, if you are getting into recurring events, the " ical cheatsheet" is worth a look. I rewrote my recurrence engine after working through that.

Google I have not found to be a problem, it is the smaller players, particularly when they start doing slightly non-standard things (Zimbra/Pc based tz's etc).

Although Google can be slow to update (ie someone updates their google calendar, you refetch the ics file (definitely not from your cache) and it does not have the update - can take an hour or so. This was no good for our school when doing their newsletter - they do a print run too from the website. SO I have resorted to creating the other side now - our own ics editor in wp.

There are various free ical scripts out there - why roll your own ? Keen for a challenge?