Hi Folks, My intention for 0.6 was to have Chandler's CalDAV client publish a VTIMEZONE for every recurring event and use UTC for non-recurring events.
Now that we're talking about displaying a timezone label to the user in 0.6, we might want to share timezone data for non-recurring events, too. To do that in the correct iCalendar way would mean uploading a VTIMEZONE for every non-recurring VEVENT, which would be a bit of a waste of bandwidth, a complete VTIMEZONE can be 5-10K, re-transmitted for every event that's changed. Fortunately intelligent serializers are allowed to snip the VTIMEZONE to only include DST information for the relevant year, so the VTIMEZONE is usually less than 1K. CalDAV offers an alternative of using TZID (timezone identifier) strings (defined by the server's entirely arbitrary timezone collection) which the spec says "should" (not must) be used. It's not clear to me how useful CalDAV's provision for a timezone collection is. The problem is that the really paranoid worry that my TZID:America/Los_Angeles isn't the same as your TZID:America/Los_Angeles. This isn't quite so paranoid if you keep in mind that during the 1970's oil embargo, the US fooled around with DST all over the place on relatively short notice. Of course, at the time nobody was using PC based PIMs to get upset about the timezone alteration! I'd rather not put a lot of energy into getting Chandler's sharing layer to poll the CalDAV server for which TZIDs it supports if that means checking if their TZIDs mean the same thing. I think it's reasonable to have Chandler not be paranoid and just assume that any CalDAV server that says it knows about America/Los_Angeles is right. Does anyone object to this as a long term plan? My plan for 0.6 is to NOT poll CalDAV server's timezone collection, and just always take the VTIMEZONE hit when syncing with CalDAV servers. Sincerely, Jeffrey _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Open Source Applications Foundation "Dev" mailing list http://lists.osafoundation.org/mailman/listinfo/dev
