Odi's astoundingly incomplete notes

New entries | Code

iCal recurrence and time zones

iCal (RFC-2445) lets you define recurrent events by setting a recurrence rule property (RECUR, section 4.3.10). RECUR takes a BYDAY parameter to define the days of the week the event will reoccur. Sample:

Whenever we speak about a day of the week we must however define the time zone we are referring to: Monday in Sidney Australia does not start at the same time as Monday in Zurich Switzerland. RRULE does not allow a time zone parameter however. Luckily RFC-2445 also says that Information, not contained in the rule, necessary to determine the various recurrence instance start time and dates are derived from the Start Time (DTSTART) entry attribute.

That leads to the following conclusion: Days of the week referred to in a RRULE are respective to the time zone defined by DTSTART.

DTSTART is defined in section and takes a time zone ID as an optional parameter. When a time zone is not specified the time must be specified in UTC format. It might be reasonable to assume the time zone used to interprete the days of the week implicitly as GMT then, but actually it is not well defined. To be certain one must always specify a time zone in DTSTART for recurring events.

So iCal is actually very precise here! When generating iCal records from Java this poses a little problem, however. Java has all the time zones information built into the stock class library: java.util.TimeZone. Unfortunately it is impossible to query this class for all the information needed to write out a time zone component in iCal (section 4.6.5). Also it is not possible to convert the times to one single time zone (like GMT) as their dailight savings time effective date may be different.

All this leads us to the final sad conclusion: Time zone information must be obtained from somewhere outside the JDK when dealing with recurrent iCal entries and if you need correct time zone handling.

posted on 2005-03-05 13:40 UTC in Code | 2 comments | permalink
You can't convert recurring events to GMT. Recurring events must be interpreted relative to the original time zone. Take for example, a meeting held at 10:00 PM America/Los_Angeles on the 1st Monday of the Month. How could you represent that to someone in London? You cannot and should not convert recurrence to GMT. The best solution as difficult as it is, is to get the Olsen time zone databases and write a parser to extract the information required to write valid timezone records according to iCal.

-George Sexton-
You are right. I discovered my mistake a while ago but never got round to updating this entry. Entry text is fixed now.