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