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" <cdaboo@apple.com> wrote:
Hi Mark,
--On November 9, 2008 3:14:04 PM -0500 Mark Cockfield <mark.cockfield@gmail.com> 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.