Use of TZID in invitations
bernhard at intevation.de
Tue Mar 29 17:32:49 CEST 2011
Am Freitag, 25. März 2011 16:54:41 schrieb Georg C. F. Greve:
> 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.
I expect different version of Outlook and Exchange to handle
any TZID string with the accompaining VTIMEZONE, as long as it is one.
Based on reading v5.0 of
It describes that VTIMEZONE has to be imported into their data structure,
one example even uses two different TZID strings to interact on one
interaction: The invitation sends "TZID:Pacific Time (US & Canada)"
and the cancelation has "TZID:Pacific Standard Time" with the same VTIMEZONE.
It also reads:
126.96.36.199.1.19.1 Property: TZID
If the system's local time zone is being exported as a VTIMEZONE, then this
name MUST be derived from the system API that supplied the time zone.
If the PidLidTimeZoneStruct property is being exported as a VTIMEZONE, this
name SHOULD be derived from PidLidTimeZoneDescription ([MS-OXOCAL] section
188.8.131.52), but MAY be set to any unique string.
so it would be okay to set TZID to a string unique in the iCalender output.
Note that most versions of outlook and exchange can only handle one VTIMEZONE
element, as this footnote claims:
<56> Section 184.108.40.206.1.19.3: Office Outlook 2003 uses the first occurrence
of the DAYLIGHT component in the VTIMEZONE. Exchange 2003, Exchange 2007, and
Exchange 2010 fail if a VTIMEZONE contains more than one DAYLIGHT component.
Exchange 2010 SP1 parses all DAYLIGHT components within a VTIMEZONE.
I was unsuccessful over half an hour to find a set of example real-world
iCalender or .ics files. Maybe somebody knows a good one.
There is the example file of libical, which I did find, it is not real world:
libical-0.46/test-data$ grep -i --no-filename tzid: * | sort -u
NEPOMUK Calendar Ontology also claims such files exist, without further
reference if this is in the wild or just a constructed example.
The timezone identifiers are plain strings. The specification states that
they should refer to timezone definitions that within the same file. RFC 2445
doesn't mention any centralised timezone database. There are perfectly
correct iCalendar files that use timezone identifiers that cannot be easily
(that is by simple string operations) mapped to those from the Olson
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>.
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