Subject: VTIMEZONE and signular TZID

From: Doug Royer <[email-masked]>
Date: Tue, 18 Apr 2000 12:22:23 -0700

I am getting back to the IANA timezone data and converting
the Olsen database into iCalendar format. I discovered
that there can be more than one name for the 'same' time zone.

Example:

	US/Pacific
	America/Los_Angeles

I think that only one should be the IANA registered name.
The other(s) some kind of alias.

I see some possible solutions:

	(1) We submit both each with identical data.

	    And only one with a TZID of '/'<name> (The official one).
	    The other with only <name>

	    From RFC2445:
	    4.2.19 Time Zone Identifier
		...
	     tzidparam  = "TZID" "=" [tzidprefix] paramtext CRLF
	     tzidprefix = "/"
		...

		BEGIN:VTIMEZONE
		TZID:/US/Pacific
		...
		END:VTIMEZONE

		BEGIN:VTIMEZONE
		TZID:America/Los_Angeles
		...
		<identical data to above>
		END:VTIMEZONE

	(2) We allow multiple TZID properties and specify that
	    only one can begin with tzidprefix. And that any
	    others are alias for the same name. And there can
	    only be more than one if exactly one has a tzidprefix.

		BEGIN:VTIMEZONE
		TZID:/US/Pacific
		TZID:America/Los_Angeles
		...
		END:VTIMEZONE

	(3) We specify a new property for the alias:

		BEGIN:VTIMEZONE
		TZID:/US/Pacific
		TZIDALIAS:America/Los_angles
		...
		END:VTIMEZONE

	(4) We could ignore the alias names and force people to
	    migrate if they used another name.

	(5) Another way would be a variation of (1), except we tweak
	    the non-standard name so that it is not valid sometime soon.
	    An RRULE with an until value in the short future.

I am leaning towards (2) - or maybe (4) COMMENTS?

Problems with (2) - how many can we allowed to be registered for
the same data? It should be discouraged to create new TZIDs just
because you can.

Another way would be a variation of (1), except we tweak the
non-standard name so that it is not valid sometime soon.
RRULE with an until value in the short future.

-Doug

---

From: Ross Finlayson <[email-masked]>
Date: Tue, 18 Apr 2000 14:56:40 -0700

>	    migrate if they used another name.
[...]
>I am leaning towards (2) - or maybe (4) COMMENTS?

I'd prefer (4): have each timezone known (as far as this iCalendar database
is concerned) by just a single id.  It makes things a lot easier all around...

	Ross.

---

From: "Colin DuPlantis" <[email-masked]>
Date: Tue, 18 Apr 2000 15:31:25 -0700

A new voice to the topic - Colin DuPlantis of Critical Path (www.cp.net).

I believe that a single approach to TZIDs would benefit.  Fresh from the
latest CalConnect conference at MIT, we discovered that allowing each app to
define its own TZIDs is a royal pain.  I say pick one method and make the
world conform...

- C

---

From: David Madeo <[email-masked]>
Date: Tue, 18 Apr 2000 19:43:09 -0400

> that there can be more than one name for the 'same' time zone.

I'd suggest asking the olsen mailing list why they have so many names for
the same timezone.  I suspect it's because of cultural and political
sensitivities.

Perhaps this needs to be a numerically indexed (so as to not offend) while
allowing whatever descriptive tag you'd like (with a default of course).
This also has the benefit of allowing i18n.

dmadeo

---

From: Doug Royer <[email-masked]>
Date: Tue, 18 Apr 2000 16:42:01 -0700

> the same timezone.  I suspect it's because of cultural and political

I don't think they care about the name. They care if the data is
accurate. So if there were 100 names for the same timezone, and
they got them all - I think they would be happy.

Fortunately it looks like there is only 2 or 3 max overlap for
one time zone entry. They call then 'links'.

I have attached 'links' with the 111 aliases.

> This also has the benefit of allowing i18n.

We would have to change iCalendar - as it uses TZID as the unique ID.
It is a text value, we could put a numeric value in text as the
value. But then we would have to invent a new property for the name.
We could in COMMENT or something - then we would have to update
the iTIP restriction tables to allow comment in a VTIMEZONE.

The TZID value is by default UTF-8. So it is already i18n ready.

-Doug

Antarctica/McMurdo	Antarctica/South_Pole
America/Adak	America/Atka
America/Tijuana	America/Ensenada
America/Indianapolis	America/Fort_Wayne
America/Indiana/Knox	America/Knox_IN
America/St_Thomas	America/Virgin
Asia/Jerusalem	Asia/Tel_Aviv
Asia/Ulaanbaatar	Asia/Ulan_Bator
Australia/Sydney	Australia/ACT
Australia/Sydney	Australia/Canberra
Australia/Lord_Howe	Australia/LHI
Australia/Sydney	Australia/NSW
Australia/Darwin	Australia/North
Australia/Brisbane	Australia/Queensland
Australia/Adelaide	Australia/South
Australia/Hobart	Australia/Tasmania
Australia/Melbourne	Australia/Victoria
Australia/Perth	Australia/West
Australia/Broken_Hill	Australia/Yancowinna
America/Porto_Acre	Brazil/Acre
America/Noronha	Brazil/DeNoronha
America/Sao_Paulo	Brazil/East
America/Manaus	Brazil/West
America/Halifax	Canada/Atlantic
America/Winnipeg	Canada/Central
America/Regina	Canada/East-Saskatchewan
America/Montreal	Canada/Eastern
America/Edmonton	Canada/Mountain
America/St_Johns	Canada/Newfoundland
America/Vancouver	Canada/Pacific
America/Regina	Canada/Saskatchewan
America/Whitehorse	Canada/Yukon
America/Santiago	Chile/Continental
Pacific/Easter	Chile/EasterIsland
America/Havana	Cuba
Africa/Cairo	Egypt
Europe/Dublin	Eire
Europe/London	GB
Europe/London	GB-Eire
Etc/GMT+0	GMT+0
Etc/GMT-0	GMT-0
Etc/GMT0	GMT0
Etc/Greenwich	Greenwich
Asia/Hong_Kong	Hongkong
Atlantic/Reykjavik	Iceland
Asia/Tehran	Iran
Asia/Jerusalem	Israel
America/Jamaica	Jamaica
Asia/Tokyo	Japan
Pacific/Kwajalein	Kwajalein
Africa/Tripoli	Libya
America/Tijuana	Mexico/BajaNorte
America/Mazatlan	Mexico/BajaSur
America/Mexico_City	Mexico/General
America/Denver	Navajo
Pacific/Auckland	NZ
Pacific/Chatham	NZ-CHAT
Pacific/Pago_Pago	Pacific/Samoa
Asia/Shanghai	PRC
Europe/Warsaw	Poland
Europe/Lisbon	Portugal
Asia/Taipei	ROC
Asia/Seoul	ROK
Asia/Singapore	Singapore
Europe/Istanbul	Turkey
Etc/UCT	UCT
America/Anchorage	US/Alaska
America/Adak	US/Aleutian
America/Phoenix	US/Arizona
America/Chicago	US/Central
America/Indianapolis	US/East-Indiana
America/New_York	US/Eastern
Pacific/Honolulu	US/Hawaii
America/Indiana/Knox	US/Indiana-Starke
America/Detroit	US/Michigan
America/Denver	US/Mountain
America/Los_Angeles	US/Pacific
Pacific/Pago_Pago	US/Samoa
Etc/UTC	UTC
Etc/Universal	Universal
Europe/Moscow	W-SU
Etc/Zulu	Zulu
Etc/GMT	GMT
Etc/UTC	Etc/Universal
Etc/UTC	Etc/Zulu
Etc/GMT	Etc/Greenwich
Etc/GMT	Etc/GMT-0
Etc/GMT	Etc/GMT+0
Etc/GMT	Etc/GMT0
Europe/Rome	Europe/Vatican
Europe/Rome	Europe/San_Marino
Europe/Oslo	Arctic/Longyearbyen
Europe/Prague	Europe/Bratislava
Europe/Istanbul	Asia/Istanbul
Europe/Belgrade	Europe/Ljubljana
Europe/Belgrade	Europe/Sarajevo
Europe/Belgrade	Europe/Skopje
Europe/Belgrade	Europe/Zagreb
America/Denver	America/Shiprock
America/Indianapolis	America/Indiana/Indianapolis
America/New_York	EST5EDT
America/Chicago	CST6CDT
America/Denver	MST7MDT
America/Los_Angeles	PST8PDT
America/Indianapolis	EST
America/Phoenix	MST
Pacific/Honolulu	HST
America/Los_Angeles	US/Pacific-New
Asia/Riyadh87	Mideast/Riyadh87
Asia/Riyadh88	Mideast/Riyadh88
Asia/Riyadh89	Mideast/Riyadh89

---

From: Antoine Leca <[email-masked]>
Date: Wed, 19 Apr 2000 12:53:01 +0200

David Madeo wrote:
> the same timezone. 

Some are already hearing you...

> I suspect it's because of cultural and political sensitivities.

I believe backward compatibility is the key reason.

( I was surprised to *not* see in Doug's list a link from
Asia/Alma-Ata to Asia/Almaty, but it appears that did not
include this particular link --and nobody minded ;-); anyway,
this is an example of the problematic...)

Also, we have a few links for small countries (like San Marin
or Vatican) that did not, and as we can see will not, have 
proper history for time zones.

Then, we have a few links for mnemonic or fame reasons, like
Antartica/South_Pole (Africa/Timbuktu is another example: it
is not a link, because LMT were different 80 years ago, but it
is merely a joke to include it as a separate timezone).

BTW, for Doug's example, the "official" one should be
America/Los_Angeles, at least if the Olson scheme is obeyed.

Antoine

---

From: Antoine Leca <[email-masked]>
Date: Wed, 19 Apr 2000 12:54:38 +0200

>                 TZIDALIAS:America/Los_angles

Just a though while browsing: why not using TZNAME here?

Antoine

---

From: John Stracke <[email-masked]>
Date: Wed, 19 Apr 2000 10:05:29 -0400

> The other(s) some kind of alias.

I think I need to disagree here--almost.  My thoughts:

First: we need to permit all the names, because people are using them (or,
at least, we can't be sure that people aren't using them, which is just as
bad).  For example, Unix boxen generally have the Olsen database installed
(on my RedHat6.2 box it's under /usr/share/zoneinfo); a program running on
a Unix box ought to be able to look at the system's timezone and use that
as its default.  Since the database is installed with all the names, the
program needs to be able to use any of them.

Next: clearly, all the names need to be standardized; otherwise, it won't
be safe to use the ones that aren't.  So all the names need to
be IANA registered.

Next: I agree that it would be best to register each set of data just
once (hence the "almost disagree").  So either we register some names with
data, and some with pointers; or we register data with multiple names.  (I
don't have strong feelings either way here.) Either way, some of the names
are aliases.

Finally: I do not think that we should distinguish syntactically between
canonical names and alias names (in your examples, by putting a slash in
front of some but not others).  This is, admittedly, partly just technical
aesthetics, but there is also a practical reason: one nice use of the alias
names is to permit future transitions.  Suppose we know that Pennsylvania
is planning to change its DST rules in a year or so, but the details aren't
nailed down yet.  We define an "America/Pennsylvania" alias, which points
to EST5EDT, and start using it in iCalendars for events in Pennsylvania.
When the DST rules are finalized, we change the alias to be a canonical
name for the new data; suddenly, all the existing iCalendars for
Pennsylvania events refer to the changed data.  (This assumes that the
legislature isn't dumb enough to change DST retroactively, so it's valid to
change the data that the iCalendar refers to, since it's in the future.
:-) If we had to distinguish between "America/Pennsylvania" and
"/America/Pennsylvania", this wouldn't work; we'd have to go through all
the existing iCalendars and change the TZIDs.

--
/==============================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.|
|Chief Scientist |=============================================|
|eCal Corp.      |If at first you don't succeed, don't go      |
[email-masked]|skydiving.                                   |
\==============================================================/

---

From: Doug Royer <[email-masked]>
Date: Wed, 19 Apr 2000 11:08:20 -0700

> Just a though while browsing: why not using TZNAME here?

According to RFC2445, TZNAME only exists inside
of a BEGIN:STANDARD or DAYLIGHT ... END:STANDARD or DAYLIGHT.

We could modify VTIMEZONE to say that TZNAME could also
included at the BEGIN:VTIMEZONE ... END:VTIMEZONE scope.

Also, TZNAME is the equivalent of the ( Olson-FORMAT + Olson-Letter/s ).
(vs Olson-Name == TZID), so we would be overloading the name.

But there can be multiple TZNAME's per RFC2445-standardc and
RFC2445-daylightc. And TZNAME's format is unregulated - so that
might be a good suggestion.

-Doug

---

From: Doug Royer <[email-masked]>
Date: Wed, 19 Apr 2000 11:34:37 -0700

John Stracke wrote:
> bad). 

I think we MUST be able to find a VTIMEZONE given common names.

(1) However are you saying that ALL must be the 'standard' IANA
    registered name?

(2) Or are you saying that only ONE (the Olson name)
    is the IANA name, and the others are just in there somewhere?

I think I was saying - (2).

> For example, Unix boxen generally have the Olsen database installed

Use all? - Yes.
All names a standard name? - I think - no.

I may have asked badly. I meant to ask, how do we specify
the non-standard names so they are fetchable? -OR- do we
specify all as standard?

> be safe to use the ones that aren't.  So all the names need to

Or do we register that FOO is the standard name, and that FOO-OLD
is another name that can be used to find the FOO VTIMEZONE data as
part of the FOO registration?

If a timezone server were setup. Could (should?) we:

	client: Ask server for FOO-OLD time zone.

	server: I know what FOO-OLD is. However it's not the
	        official name, so I'll return:

		success - code followed by:

			BEGIN:VTIMEZONE
			TZID:FOO
			...
			<unspecified-at-this-time>:FOO-OLD
			...
			END:VTIMEZONE.

So that you can get what you need, but are also informed of what
you should ask for in the future (ask for FOO).
	
> don't have strong feelings either way here.) Either way, some of the names

(1) We currently do not have any way to do a 'pointer' inside
    if VTIMEZONE data.

(2) I think you are asking the same question as me.

> front of some but not others). 

This is already part of RFC2445, search for the string 'tzidprefix'.
It is how the WG already decided to identify IANA registered TZIDs.

My question is do we register all (The Olson alias people seem so far
to be saying - no - they exist for historical use), or just the
current names.

> This is, admittedly, partly just technical

That's not exactly the way it works.

Using your example, If 'America/Pennsylvania' already existed and
was registered by IANA, then its IANA registered name (It's IANA TZID) is
going to be '/America/Pennsylvania' (leading slash - per RFC2445).

So if it were to be updated, the TZID could be the same. However
the data inside would be updated. And the old value would have
at least a new UNTIL to it's RRULE. And the DTSTAMP would be updated.
(I think we need to make DTSTAMP a MUST for registration).

If the name 'America/Pennsylvania' were not already registered.
Then there is no conflict. Once it were to be registered, then
'that' new data 'is' the data and the TZID would be
'/America/Pennsylvania'. So there would be no issue.

It would NOT be possible to have 'America/Pennsylvania' and
'/America/Pennsylvania' BOTH registered as the leading slash
means it is registered.

Asking for 'America/Pennsylvania' would be asking for
any VTIMEZONE that had this name. being returned the
same name with the 'tzidprefix' simply tells you it is a 
registered name.

Or did I miss your point ;-)

-Doug

---

From: John Stracke <[email-masked]>
Date: Wed, 19 Apr 2000 17:21:05 -0400

> (1) However are you saying that ALL must be the 'standard' IANA

I'm saying that all the names must be registered with IANA, whether they're
aliases or not.

(a) If only The Official Name is registered, then we have a uniqueness
problem--IANA won't be able to protect us from registering a new Official Name
that conflicts with an existing alias.

(b) If aliases are not registered, then they can't be used, because the sender
can't be sure the recipient can understand them.

> All names a standard name? - I think - no.

If they're going to be used, they have to be standardized.

> you should ask for in the future (ask for FOO).

That sounds good to me--except that we shouldn't advise clients to use FOO in
the future.  If someone typed in an alias, it may be for a good reason (as in my
Pennsylvania scenario).

> (1) We currently do not have any way to do a 'pointer' inside

No, it'd have to be in the IANA registry somehow.

> (2) I think you are asking the same question as me.

Could be.

> It is how the WG already decided to identify IANA registered TZIDs.

Fine, then they all need the prefix, since they all need to be registered.

> '/America/Pennsylvania'. So there would be no issue.

The point is that it should be possible to change a registration from an alias
to a non-alias, for transition cases: create the alias to point to the current
data, then change the registration when the new data is available.

--
/===============================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own. |
|Chief Scientist |==============================================|
|eCal Corp.      |"Dinner Special: Turkey $2.35; Chicken or Beef|
[email-masked]|$2.25; Children $2.00."                       |
\===============================================================/