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-3 F1B-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