[Dev] More on Sharing timezones on a CalDAV server

Jeffrey Harris jeffrey at skyhouseconsulting.com
Tue May 3 15:40:34 PDT 2005

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.


More information about the Dev mailing list