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
Hi Mark, --On December 5, 2008 8:45:55 PM -0500 Mark Cockfield <mark.cockfield@gmail.com> wrote:
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?
You should not consider the timezone service api stable right now (though I don't anticipate any major changes in the short term). The Calendaring & Scheduling consortium has a technical committee working on a formal standardization of a timezone service and they will be producing an HTTP-based api for that. We will likely adopt that once it is published. The other goal of the CalConnect work is to get rid of the need to pass the VTIMEZONE data by value, and instead allow by-reference pointers. i.e. the client would not need to send the VTIMEZONE at all - it just makes sure it uses a "standard" TZID value that the server knows about. -- Cyrus Daboo
Hi Cyrus, The activity at CalConnect is what led me to believe that this service is the direction that timezone handling is heading. Is it reasonable to assume that any changes would be less than drastic? I can accept a slightly moving target given that the alternative is to parse the tzdata record, which I would have to persist, for a given tzid to determine how to adjust. Mark On 12/5/08 9:08 PM, "Cyrus Daboo" <cdaboo@apple.com> wrote:
Hi Mark,
--On December 5, 2008 8:45:55 PM -0500 Mark Cockfield <mark.cockfield@gmail.com> wrote:
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?
You should not consider the timezone service api stable right now (though I don't anticipate any major changes in the short term). The Calendaring & Scheduling consortium has a technical committee working on a formal standardization of a timezone service and they will be producing an HTTP-based api for that. We will likely adopt that once it is published.
The other goal of the CalConnect work is to get rid of the need to pass the VTIMEZONE data by value, and instead allow by-reference pointers. i.e. the client would not need to send the VTIMEZONE at all - it just makes sure it uses a "standard" TZID value that the server knows about.
participants (2)
-
Cyrus Daboo
-
Mark Cockfield