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" <[EMAIL PROTECTED]> wrote: > Hi Mark, > > --On December 5, 2008 8:45:55 PM -0500 Mark Cockfield > <[EMAIL PROTECTED]> 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. _______________________________________________ calendarserver-users mailing list calendarserver-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/calendarserver-users
