I’m trying to devise a timezone strategy for a RIA client I am hoping to keep fairly thin. Upon contemplating the complexity of the Olson tzdata and the discovery that other calendar clients don’t reliably handle the issue well...this is an calendar object written by iCal to the calendar server:
PUT /calendars/__uids__/ada9f1a1-1172-5784-8780-d67f9747dc7c/calendar/E4768A09-3F1B-4778-987B-B62B92662ED2.ics HTTP/1.1
User-Agent: DAVKit/3.0.4 (652); CalendarStore/3.0.5 (841); iCal/3.0.5 (1270); Mac OS X/10.5.5 (9F33)
Authorization: Basic Y2xpZW50OnRyYWlubWU=
Content-Type: text/calendar
If-Match: "a918de3ca423b993d5603b87590da2f0"
Content-Length: 760
Connection: keep-alive
Host: localhost:8008
BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Apple Inc.//iCal 3.0//EN
CALSCALE:GREGORIAN
BEGIN:VTIMEZONE
TZID:America/Detroit
BEGIN:STANDARD
TZOFFSETFROM:-0400
TZOFFSETTO:-0500
DTSTART:19671029T020000
RRULE:FREQ=YEARLY;UNTIL=20061029T060000Z;BYMONTH=10;BYDAY=-1SU
TZNAME:EST
END:STANDARD
BEGIN:DAYLIGHT
TZOFFSETFROM:-0500
TZOFFSETTO:-0400
DTSTART:19870405T020000
RRULE:FREQ=YEARLY;UNTIL=20060402T070000Z;BYMONTH=4;BYDAY=1SU
TZNAME:EDT
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VTODO
PRIORITY:0
SEQUENCE:4
DTSTART;TZID=America/Detroit:20040101T120000
UID:E4768A09-3F1B-4778-987B-B62B92662ED2
DTSTAMP:20081206T010207Z
SUMMARY:Test w/Due Date
CREATED:20081206T010119Z
X-APPLE-SORT-ORDER:2147483647
DUE;VALUE=DATE:20081210
END:VTODO
END:VCALENDAR
It seems to me the ideal approach would be to rely on the CalendarServer’s timezone service. Use it to retrieve the timezone components I Include in the components I create, and do an expand query to determine the currently observed offsets for timezones for which I need to adjust.
So my questions are: is anyone else using this service, and to the CalendarServer developers, is this service something I may rely upon?
Regards,
Mark