Odi's astoundingly incomplete notesNew 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:
RRULE:FREQ=WEEKLY;BYDAY=MO,TU,WE,TH,FRWhenever 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 22.214.171.124 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.