Subject: Timezone TZID clashes

From: Damon Chaplin <[email-masked]>
Date: Tue, 13 Mar 2001 18:46:59 +0000

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

---

From: John Stracke <[email-masked]>
Date: Wed, 14 Mar 2001 10:42:01 -0500

> created by an earlier version of the application.

Let's see.  If a VCALENDAR contains a TZID pointing to a VTIMEZONE in that same
VCALENDAR, then obviously the application should use that VTIMEZONE, not the
one in its own configuration.  But, if the application changes the TZIDs to get
uniqueness, then it's changed that VCALENDAR, and it's going to run into
trouble if it's doing iTIP.  So I believe the correct approach is to define a
search path: "first look in the current VCALENDAR, then look in your own
configuration, then see if you can download the VTIMEZONE from somewhere"
(assuming we ever get a global VTIMEZONE repository).

--
/==============================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.|
|Chief Scientist |=============================================|
|eCal Corp.      |Think of it as evolution in action.          |
[email-masked]|                                             |
\==============================================================/

---

From: Damon Chaplin <[email-masked]>
Date: Thu, 15 Mar 2001 03:35:30 +0000

> (assuming we ever get a global VTIMEZONE repository).

I don't think that really solves the conflicts, though.

If the app loads/receives an iCalendar file with, for example, a "Europe/London"
VTIMEZONE calendar component, and the user then creates another time with the
timezone set to "Europe/London", then we have 2 "Europe/London" VTIMEZONE
components to place in the iCalendar file.

If you're right about iTIP problems, then it looks like it is impossible to
resolve conflicts. This also suggests using a product ID and version in the TZID
like I proposed so we avoid conflicts.

One other thing I forgot is that currently VTIMEZONE components only have to
cover the time range used within the iCalendar file. I think this is going to
cause problems as well - how do you know which VTIMEZONE to keep when you have
2 VTIMEZONEs which are the same except for the time range that they cover?
Are you supposed to merge the subcomponents? That would be very difficult.
So I think it is better if a VTIMEZONE component must cover the entire time range.

Damon

---

From: John Stracke <[email-masked]>
Date: Thu, 15 Mar 2001 10:11:04 -0500

> components to place in the iCalendar file.

OK, yeah, in that case, the CUA may need to put them both in, and rename one of
them.  A slightly smarter CUA, though, would check to see whether the existing
VTIMEZONE agrees with the one it knows.

> like I proposed so we avoid conflicts.

Mmm, no, I don't think that would help, necessarily.

> cover the time range used within the iCalendar file.

I really can't see any sensible implementation automatically narrowing down the
VTIMEZONE it sends out.  It's going to be much more efficient just to send the
component taken from its configuration; working up an algorithm to reduce that
component to just what's necessary to cover a certain range would be ludicrously
painful.  Besides, what happens if the recipient COUNTERs with a time outside that
original range, a time at which the original VTIMEZONE disagrees with the reduced
one?

> So I think it is better if a VTIMEZONE component must cover the entire time range.

Er...but define "the entire time range".  From now until the end of time?

I would say instead: a CUA SHOULD send VTIMEZONE components which cover as large a
time range as the CUA knows for that timezone.

--
/================================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.  |
|Chief Scientist |===============================================|
|eCal Corp.      |"Lollygaggers will be shot on sight!" "I didn't|
[email-masked]|say that!" "I was paraphrasing."               |
\================================================================/

---

From: John Stracke <[email-masked]>
Date: Thu, 15 Mar 2001 16:46:06 -0500

> Mmm, no, I don't think that would help, necessarily.

What I meant to add, and didn't: product IDs are pretty unreliable in the first place
(consider HTTP User-Agent:); and they get worse if different installations of the
product may have different sets of timezone data.  For example, a Unix CUA might
extract the system timezone information and send that out as VTIMEZONEs; the definition
of each VTIMEZONE then depends on the OS version as well as the product version.

|eCal Corp.      |E pui muove! -- Galileo                      |

---

From: "Graham Gilmore" <[email-masked]>
Date: Thu, 15 Mar 2001 17:12:16 -0500

----- Original Message -----
From: "John Stracke" <[email-masked]>
To: <[email-masked]>
Sent: 15 March, 2001 16:46
Subject: Re: Timezone TZID clashes

> of each VTIMEZONE then depends on the OS version as well as the
product version.

    The point of adding the product IDs would be to ensure the
uniqueness of a TZID received from an external source (or at least,
unique with respect to a CUA's own internal timezones), not to allow a
CUA to infer that given the product IDs are the same, therefore the
TZIDs with the same name refer to identical information.  It basically
boils down to, "ok this doesn't come from me - I'd better ignore the
TZID/TZNAME and look only at the actual rule content."  And maybe the
first part of that phrase is even assuming too much.
    On the other hand, tacking the PRODUCTID on to the TZID starts to
become very close, in spirit, at least, to violating section 4.7.3 of
the RFC which states "This property [PRODUCTID] SHOULD not be used to
alter the interpretation of an iCalendar object beyond the semantics
specified in this memo.  For example, it is not to be used to further
the understanding of non-standard properties."
    Maybe generating a new UID for the TZID each time one is needed by a
VTIMEZONE would be a good way to do it.

    Graham

---

From: Damon Chaplin <[email-masked]>
Date: Thu, 15 Mar 2001 17:52:51 +0000

> Mmm, no, I don't think that would help, necessarily.

Why not?

If you have a unique product ID and a unique VTIMEZONE version number in the TZID,
then how can you have a conflict?

> time range as the CUA knows for that timezone.

Yep. Of course timezones change over time so you'll have to release new versions of
the VTIMEZONE components, which is why I wanted to put a version number in the TZID.

Damon

---

From: Damon Chaplin <[email-masked]>
Date: Thu, 15 Mar 2001 22:22:57 +0000

> of each VTIMEZONE then depends on the OS version as well as the product version.

That's true, but if we specify that the product ID and version number are supposed to
uniquely identify the VTIMEZONE data, then if an application doesn't do that it doesn't
conform to the spec.

Does anyone have any better ideas for resolving TZID clashes?
(I'm supposed to have this all implemented in the next few weeks so think fast!)

Damon

---

From: John Stracke <[email-masked]>
Date: Thu, 15 Mar 2001 17:48:00 -0500

Graham Gilmore wrote:

> uniqueness of a TZID received from an external source

Can't do that either.  If I use iTIP to invite two people using CUAs which
are the same product and version, I can't be sure that they've got the same
set of timezones.

--
/===============================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own. |
|Chief Scientist |==============================================|
|eCal Corp.      |Whose cruel idea was it for the word "lisp" to|
[email-masked]|have an "S" in it?                            |
\===============================================================/

---

From: John Stracke <[email-masked]>
Date: Thu, 15 Mar 2001 17:49:45 -0500

> uniquely identify the VTIMEZONE data, then if an application doesn't do that it doesn't

But it's not *possible*.  A CUA which gets its timezone data from an external source (even a
data file packaged with the app) cannot be sure that they haven't changed from one
invocation of the program to the next.  If we were going to issue standards mandating the
impossible, we wouldn't be engineers; we'd be politicians.

--
/=================================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.   |
|Chief Scientist |================================================|
|eCal Corp.      |"If there's anything The Flintstones have taught|
[email-masked]|us, it's that pelicans can be used to mix       |
|                |cement." -- Homer Simpson                       |
\=================================================================/

---

From: Damon Chaplin <[email-masked]>
Date: Fri, 16 Mar 2001 21:00:35 +0000

> impossible, we wouldn't be engineers; we'd be politicians.

I'm not sure that is a problem. But I've just realized that a malicious app
could use a fake product id and version number in an iTIP message and mess
up an applications VTIMEZONEs, so my idea won't work.

So I'm now back to renaming TZIDs when they clash. So we'd better check that
iTIP can handle renamed TZIDs OK.

Damon

---

From: Federico Mena Quintero <[email-masked]>
Date: Fri, 16 Mar 2001 21:01:31 -0600

> of each VTIMEZONE then depends on the OS version as well as the product version.

The system's timezone database should be a set of VTIMEZONEs, not the
current Unix mess.

[We were discussing doing this as the lower-level mechanism for the
Ximian Setup Tools, possibly translating VTIMEZONEs to Unix timezone
data for compatibility with legacy stuff.]

  Federico

---

From: John Stracke <[email-masked]>
Date: Sat, 17 Mar 2001 13:37:48 -0500

> The system's timezone database should be a set of VTIMEZONEs, not the

(a) That's as may be; but most application developers don't get to dictate how the system is
built.

(b) Removing the translation step would not change that fact that the VTIMEZONEs the app
sends out would depend on the OS version instead of the app version.

(c) If the OS used VTIMEZONEs instead of something custom, then it would be *easier* to
modify, and you'd have *more* variance among installations.

--
/================================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.  |
|Chief Scientist |===============================================|
|eCal Corp.      |I'm not a bibliophile, I'm a bibliophiliac. Put|
[email-masked]|me in a bookstore, & my wallet bleeds.         |
\================================================================/