Timezone TZID clashes

[Damon Chaplin <damon@xxxxxxxxxx>]

What should an application do when it has 2 VTIMEZONE components
with conflicting TZIDs?

This may happen when an application receives a message from
another iCalendar app which uses the same TZIDs, or when an
application loads a .ics file it created itself, or that was
created by an earlier version of the application.

The application should probably try to ensure that the VTIMEZONE
associated with a particular event remains the same, or people may
turn up to meetings at the wrong time!

So it would have to rename one of the TZIDs, and all references to it.
For example, if there were 2 VTIMEZONEs with a TZID of "Europe/London",
it would rename one of them to something like "Europe/London(2)" as well
as the TZID references in the DATE/TIME values which refer to it.
(Though this could lead to a slightly confusing interface for users.)

We also need a way to check if the 2 VTIMEZONE components are actually
the same, so we could avoid the renaming. Currently the only way to do
that is to compare every sub-component in the VTIMEZONEs & their properties.
It would be better if the VTIMEZONE components had a PRODID property
and the LAST-MODIFIED property was made mandatory. We could then compare
VTIMEZONES by just comparing the PRODID and LAST-MODIFIED.


Ideally, I think the TZID property/parameter should include a product ID and
a VTIMEZONE version within the TZID strings, e.g. "Europe/London:libical-3".
Then we wouldn't have any problems with conflicts at all.

(For libical, my current plan is to name TZIDs like this and then just
ignore any TZID conflicts, i.e. the first VTIMEZONE found with that TZID
is used. It seems like too much unnecessary effort to resolve conflicts.)

Damon