VTIMEZONE and signular TZID

[Doug Royer <Doug.Royer@xxxxxxxxxxxx>]

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