A summary of sorts (was: Re: Why and when storing local time? (Re: Basic rationale of the KEP #2 design))
bernhard at intevation.de
Fri Apr 1 16:10:44 CEST 2011
Am Donnerstag, 31. März 2011 18:16:19 schrieb Georg C. F. Greve:
>>>The only open question I still have is whether or not a cache of the
>>> static rules which would also allow to handle ficticious time zones which
>>> VTIMEZONE allows is worth the complication and bloat.
>>> Nobody seems willing to advocate for it strongly,
> > I did and still do, in case you forgot.
I believe we can do without this information.
Overall it seems that implementations never implement iTIP fully, see the
footnote of VTIMEZONEs in most exchange and outlook versions above. But they
try. As there seem to be many, many options, the full compatibility can only
be reached by saving the original iCalender file, I doubt most clients will
do this, nor that it is useful.
So we could do the approach: The Kolab format community maintains a mapping
of real-world TZIDs to our tz-id. Once we see new TZIDs in the wild, we add
to the mapping. If we see repeated random TZIDs in the wild, we change the
format to add a <vtimezone-legacy-but-authoritative>.
In addition we could say that client should raise the fact to the user, once
they encounter VTIMEZONE info with a TZID that cannot be found in the table.
And they SHOULD offer to at least save the first event or all events in
I know this is not very comfortable, but there would be no way to get rid of
saving VTIMEZONE everywhere, if we did not go by the mapping approach.
Overall the mapping approach is something I like better.
> > An I still believe it should be
> > the primary source of TZ-data for the Clients accessing that
> > Kolab-object, and the rules to dynamically update that in-format TZ-data
> > should be well defined.
> Alright. As you may have seen, using static information as the primary
> source of information is not shared by most people.
This would be discussion b).
> Would you be willing to live with a way to encode this format in KEP 2 as a
> cache that is subordinate to the dynamic TZ-ID based lookup, but may be
> used where such lookup is too hard and can be updated under certain
Note that for CUSTOM timezones, this "cache" would be the authoritative
Managing Director - Owner: www.intevation.net (Free Software Company)
Deputy Coordinator Germany: fsfe.org. Board member: www.kolabsys.com.
Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 198 bytes
Desc: This is a digitally signed message part.
More information about the format