A summary of sorts (was: Re: Why and when storing local time? (Re: Basic rationale of the KEP #2 design))

Bernhard Reiter 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.
From http://kolab.org/pipermail/kolab-format/2011-March/001294.html

  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 
absolute values.

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
> conditions?

Note that for CUSTOM timezones, this "cache" would be the authoritative 
definition.


-- 
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...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.kolab.org/pipermail/format/attachments/20110401/81f9d5c5/attachment.sig>


More information about the format mailing list