Greetings, I think I am missing something. I have set the America/Detroit timezone on the calendar collection. I have an event in the CalendarServer created with iCal:
BEGIN:VCALENDAR VERSION:2.0 PRODID:-//Apple Inc.//iCal 3.0//EN CALSCALE:GREGORIAN BEGIN:VTIMEZONE TZID:America/Detroit BEGIN:DAYLIGHT TZOFFSETFROM:-0500 TZOFFSETTO:-0400 DTSTART:20070311T020000 RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=2SU TZNAME:EDT END:DAYLIGHT BEGIN:STANDARD TZOFFSETFROM:-0400 TZOFFSETTO:-0500 DTSTART:20071104T020000 RRULE:FREQ=YEARLY;BYMONTH=11;BYDAY=1SU TZNAME:EST END:STANDARD END:VTIMEZONE BEGIN:VEVENT SEQUENCE:3 TRANSP:OPAQUE UID:9D7A5B23-B956-49E7-B1AE-90155506531D DTSTART;TZID=America/Detroit:20081113T110000 DTSTAMP:20081109T193054Z SUMMARY:Another Event CREATED:20081109T193030Z DTEND;TZID=America/Detroit:20081113T120000 END:VEVENT END:VCALENDAR
I am doing a calendar-query REPORT:
<C:calendar-query xmlns:C="urn:ietf:params:xml:ns:caldav" xmlns:D="DAV:"> <D:prop> <C:calendar-data> <C:expand start="20081101T000000Z" end="20090301T000000Z"/> <C:comp name="VCALENDAR"> <C:allprop /> <C:allcomp /> </C:comp> </C:calendar-data> </D:prop> <C:filter> <C:comp-filter name="VCALENDAR"> <C:comp-filter name="VEVENT"> <C:time-range start="20081101T000000Z" end="20090301T000000Z"/> </C:comp-filter> </C:comp-filter> </C:filter> <C:timezone> <![CDATA[BEGIN:VCALENDAR VERSION:2.0 PRODID:-//ABC Corp//ABC App 0.1//EN BEGIN:VTIMEZONE TZID:America/Detroit BEGIN:DAYLIGHT TZOFFSETFROM:-0500 TZOFFSETTO:-0400 DTSTART:20070311T020000 RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=2SU TZNAME:EDT END:DAYLIGHT BEGIN:STANDARD TZOFFSETFROM:-0400 TZOFFSETTO:-0500 DTSTART:20071104T020000 RRULE:FREQ=YEARLY;BYMONTH=11;BYDAY=1SU TZNAME:EST END:STANDARD END:VTIMEZONE END:VCALENDAR ]]> </C:timezone> </C:calendar-query>
Yet the response has the start and end times being specified in UTC time even though they also specify a TZID:
<multistatus xmlns="DAV:"> <response> <href> /calendars/__uids__/abc/calendar/9D7A5B23-B956-49E7-B1AE-90155506531D.ics </href> <propstat> <prop> <calendar-data xmlns="urn:ietf:params:xml:ns:caldav"> <![CDATA[BEGIN:VCALENDAR VERSION:2.0 CALSCALE:GREGORIAN PRODID:-//Apple Inc.//iCal 3.0//EN BEGIN:VEVENT UID:9D7A5B23-B956-49E7-B1AE-90155506531D DTSTART;TZID=America/Detroit:20081113T160000Z DTEND;TZID=America/Detroit:20081113T170000Z CREATED:20081109T193030Z DTSTAMP:20081109T193054Z SEQUENCE:3 SUMMARY:Another Event TRANSP:OPAQUE END:VEVENT END:VCALENDAR ]]> </calendar-data> </prop> <status> HTTP/1.1 200 OK </status> </propstat> </response> </multistatus>
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. Regards, Mark
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. -- Cyrus Daboo
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.
participants (2)
-
Cyrus Daboo
-
Mark Cockfield