Use of TZID in invitations (Re: Basic rationale of the KEP #2 design)
Georg C. F. Greve
greve at kolabsys.com
Fri Mar 25 16:54:41 CET 2011
On Tuesday 22 March 2011 17.14:16 Bernhard Reiter wrote:
> I agree that this is the right question. It would also be interesting
> how other clients like Outlook would deal with the situation.
Indeed. Any insight others could share on this would be appreciated.
> Note that it could well be the case that the TZID of iTIP just is
> an arbitrary string, but the corresponding VTIMEZONE definition
> matches a real timezone. However doing this match probably is untrivial,
> so it would be hard to detect.
Actually I would say it's pretty much impossible.
Because a match would look like "this is the set of rules that was in effect in
the years 1950 - 1960 in Germany" and there will likely be more than one
match. Which one do you take?
In the end, this gets VERY complex VERY fast, and for questionable benefit.
> I agree with both points about if in-format tz-data would to be used.
> My <original-vtimezone> tag was meant to be such a CUSTOM block.
Yes, I know.
Only I would not limitd it to "original vtimezone", but use it as an explicit
caching rule, which will be of lower hierarchy than the TZID, so clients know
which one to follow when in doubt and should use the dynamic approach whenever
they can, but can fall back on the cache if that is their only option.
It would complicate the overall handling of Kolab XML objects and bloat them
somewhat, but not so much that it would likely cause a major issue, I believe.
In other words: It's crufty, and for unknown benefit, but if it helps to finally
lay this issue to rest, maybe that is what we have to do.
Georg C. F. Greve
Chief Executive Officer
Kolab Systems AG
e: greve at kolabsys.com
t: +41 78 904 43 33
pgp: 86574ACA Georg C. F. Greve
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 308 bytes
Desc: This is a digitally signed message part.
More information about the format