Hi Cyrus, Thanks for the clarification. I guess I was assuming that by specifying the timezone the times would be adjusted to that timezone, or in this case left in their native timezone. Apparently I get to look forward to yet more quality time with the RFCs...I don't suppose you could be persuaded to incorporate an interesting subplot in the next revision, maybe a bit of intrigue...well, thought I'd ask.
Mark On 11/10/08 8:14 PM, "Cyrus Daboo" <[EMAIL PROTECTED]> wrote: > Hi Mark, > > --On November 9, 2008 3:14:04 PM -0500 Mark Cockfield > <[EMAIL PROTECTED]> wrote: > >> This is not the behavior I was expecting. >> >> I think I am missing something but I am unable to see the forest for the >> trees. Any insight would be appreciated. > > This is the correct behavior. The <expand> element in the <calendar-data> > element requires the server to return expanded components using UTC for > date-time values (as per the CalDAV spec). The reasoning behind this is > that we expected "thin" clients to be the ones using <expand> and for them > doing the timezone recurrence expansion calculations would be too complex, > so returning everything as UTC and allowing the clients to apply their own > offsets for viewing makes sense. > > If you really want to get back the original localtime values, remove the > <expand> element. You will then get back the data with appropriate > VTIMEZONEs included with each calendar resource. > > Note that the purpose of providing a timezone to the server is to give the > server an appropriate basis for time-range queries against floating time > and all-day events. _______________________________________________ calendarserver-users mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/calendarserver-users
