Outlook vs Kontact iCalender TZID interpretation

Albrecht Dreß albrecht.dress at lios-tech.com
Fri Sep 11 17:28:42 CEST 2009


Am Freitag 11 September 2009 16:49:07 schrieb Gunnar Wrobel:
> Quoting Bernhard Reiter <bernhard at intevation.de>:
> >> <snip>
> >> DTSTART;TZID=Europe/Berlin:20090826T150000
> >> DTEND;TZID=Europe/Berlin:20090826T153000
> >> </snip>
> >>
> >> I didn't look into the RFC yet,
> >
> > You probably should for a good interpretation, at least that would be my next
> > step if I had this as a support case on my desk. :)

Afaict, the parameter is fine, according to RFC 2445, Sect. 4.2.19.  However, the interpretation seems to be anything but trivial.  Quoting the RFC:

<quote>
Note: This document does not define a naming convention for time zone identifiers. Implementers may want to use the naming conventions defined in existing time zone specifications such as the public-domain Olson database [TZ]. The specification of globally unique time zone identifiers is not addressed by this document and is left for future study.
</quote>

> > This leaves Kontact, Outlook or the Kolab Webclient as possible culprits.

I believe it's Outlook then... (which is also the easiest one to blame ;-)

> > My enterprise35 does not add the timezone information, which seems to be good to avoid the issue.

Reading the RFC's explanation, I completely agree with you!

> > My enterprise4 client does, though. Anyway, if this is an interoperability issue we might need to change Kontact even if it is the Outlook side that is wrong.
> >
> > I think we should create an issue for this.
> 
> Did somebody create an issue?

No yet, but I can do that.

Thanks, Albrecht.




More information about the users mailing list