Subject: Omit VTIMEZONE when using global identifiers?

From: Eric Busboom <[email-masked]>
Date: Tue, 3 Apr 2001 13:09:01 -0700 (PDT)

RFC2445 section 4.2.19 mentions that a "/" in front of a timezone name
indicates a globally unique name, but it explicitly avoids identifying
these globally unique names. 

We've talked about using the Olsen database for these global identifiers,
but have not made any concrete decisions. Can we tie this down now? Do we
have a global timezone registry? If not, what will it take to get one?

Also, if we define the global TZ registry, can we remove the requirement
to include a VTIMEZONE in a component when the TZID parameters reference
global names? 

eric.

---

From: George Babics <[email-masked]>
Date: Thu, 05 Apr 2001 09:35:03 -0400

> have a global timezone registry? If not, what will it take to get one?

  We were trying to get the Olson database registered with IANA. Last
I heard we contacted someone from IANA and now are waiting for a reply
from someone at Olson.  Pat or Bob make haven more information?

> to include a VTIMEZONE in a component when the TZID parameters reference

  Good idea.
  
  What happens when an application encounters a timezone from the
the global TZ registry that was recently added, and that the application
is not aware about? Should it assume that it came from the global registry
and print a message saying something like: "your timezone registry may be out
of date, please update." 

  We also have to worry about old applications that support iCalendar, iMIP and
iTIP, since they expect a timezone. However, for CAP it should be OK.

---

From: John Stracke <[email-masked]>
Date: Fri, 06 Apr 2001 10:17:19 -0400

George Babics wrote:

> is not aware about?

Or, worse, if it's a TZID that the receiver recognizes, but whose definition has
changed.  The sender knows the change, the receiver doesn't.  Result: the receiver
will show up to the meeting at the wrong time--unacceptable.

I think we have to keep the VTIMEZONE in, no matter what.

--
/================================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.  |
|Chief Scientist |===============================================|
|eCal Corp.      |Both candidates are better than a megalomaniac |
[email-masked]|mutant lab mouse bent on world domination...but|
|                |it's pretty close.                             |
\================================================================/

---

From: David Madeo <[email-masked]>
Date: Fri, 06 Apr 2001 10:39:54 -0400

> I think we have to keep the VTIMEZONE in, no matter what.

Or a version number with the TZID.  The tz database has a simple yearletter code (eg:
2001b) for it's versioning.  If the ietf does somehow codify the tz database, that
might come in handy.

dmadeo

---

From: John Stracke <[email-masked]>
Date: Fri, 06 Apr 2001 10:57:05 -0400

David Madeo wrote:

> Or a version number with the TZID.

That's almost as bad--then you send me a TZID with a version number I don't recognize.
I'm not misleading the user any more, but I'm not getting them useful information,
either.

I have a basic question about this thread: WHY?

We have a *wonderful* mechanism which lets two people schedule a meeting, at the same
time, even if their CUAs don't have the same timezone definitions.  Why are we talking
about sabotaging it?

--
/================================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.  |
|Chief Scientist |===============================================|
|eCal Corp.      |Yes, sir, we've graphed the data. It's a smiley|
[email-masked]|face, sir.                                     |
\================================================================/

---

From: Alan Davies <[email-masked]>
Date: Fri, 06 Apr 2001 10:52:00 -0400

>I think we have to keep the VTIMEZONE in, no matter what.

So what's the point of using the unique name? All of the
timezone information is available in the VTIMEZONE, and it
has to be parsed (unless the names are also unique by TZ db
version) to double-check that the sender isn't using an
older/newer version of the TZ database than the receiver.

One reason for using the unique TZ name could be to ensure
that both sender and receiver refer to the timezone by the
same Country/City pair, when multiple cities share the same
timezone rules. Perhaps some users would object to a system
that, for example, always assumes EST is /US/New-York when
receiving iCalendar, even when the sender specifies the
timezone as /Canada/Toronto.

--Alan

---

From: John Stracke <[email-masked]>
Date: Fri, 06 Apr 2001 11:45:07 -0400

Alan Davies wrote:

> So what's the point of using the unique name?

In iCalendar--not much.  In the UI, it might be vaguely useful for people to
be able to carry their knowledge from CUA to CUA.

--
/=================================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.   |
|Chief Scientist |================================================|
|eCal Corp.      |I will not buy this .signature, it is scratched.|
[email-masked]|                                                |
\=================================================================/

---

From: Damon Chaplin <[email-masked]>
Date: Mon, 23 Apr 2001 21:33:54 -0400

> be able to carry their knowledge from CUA to CUA.

I agree with John here. I don't see much use at present for the globally
unique
identifiers, except for the GUI. Possible version updates mean you can't
rely
on the VTIMEZONE being the same.

(But one important benefit would be for CUAs to store translations of
the standard
timezone names, so they are of more use to non-English speakers.)

Damon

---

From: John Stracke <[email-masked]>
Date: Tue, 24 Apr 2001 10:14:19 -0400

> timezone names, so they are of more use to non-English speakers.)

Yes, that would be nice.  Of course, a VTIMEZONE can have multiple TZNAMEs; but
that works only if the sender's CUA knows the translation for the receiver's
language.  If I'm, say, Estonian (~1 million speakers), and I'm trying to
schedule a meeting with someone in Japan, a translation table in my CUA would be
very useful.

--
/================================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.  |
|Chief Scientist |===============================================|
|eCal Corp.      |"Fly Heisenberg Airlines! We may not know where|
[email-masked]|we are, but we're making real good time." --   |
|                |_Synners_ by Pat Cadigan                       |
\================================================================/