>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.
This is normal. Nothing unusual about this. See my previous note.
<snip>
>I think that only one should be the IANA registered name.
>The other(s) some kind of alias.
Do we mean the TZNAME or TZID? iCalendar allows multiple TZNAMEs for the same time zone definition. In the OLSEN db, I believe the two concepts are merged into one. In iCalendar, there can be only one TZID for a given definition, but that definition can have multiple "names" or TZNAME properties. COMMENT property is also allowed.
>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>
<snip>
> (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.
<snip>
> (3) We specify a new property for the alias:
<snip>
> (4) We could ignore the alias names and force people to
> migrate if they used another name.
<snip>
> (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.
By "alias", we should mean a time zone definition created by someone other than the official owner for the given time zone definition (e.g., some programmer trying to make sense out of this historical mess ;-). Any of the official time zone definitions, captured by the OLSEN db should be retained as individual time zone definitions by the IANA registry. We should also recognize that as the geographical boundaries for legal locales gets redefined, the IANA will have new time zone definitions added that will possibly look like duplicate definitions for the same time zone (e.g., we could get two European definitions for Kosovo).
May be some of the apparent cases of an "alias" are actually intended to be different time zone definitions. For example, there could be official, but historical changes to the names that result in two independent definitions for the same time zone. Both of these need to remain in the registry. Or, there could be two legal entities for the same "near geography". For example, a US definition for an antartic base, but a UN definition for the UN protectorate. Cases, such as these two independent definitions need to be remain distinct in the IANA registry also.
In addition, once a definition is placed into the IANA registry, it should not be removed.
>I am leaning towards (2) - or maybe (4) COMMENTS?
What is wrong with (1)? This seems the only practical solution, given that we will have to have procedure for adding entries to the IANA registry and that any one of these additions could appear to be a duplicate definition for the same time zone definition. But, it might not be. It might be a definition for a legal time zone that has the same UTC offset as an existing entry in the IANA registry.
>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.
Since we don't control the definition of time zones, only the definition of how they are represented in the IANA registry, this is a moot question. If xyz country decides to define a time zone then we need to add it. If the xyz country has a brain fart and decides to redefine the time zone, then we need to add that one. We aren't time zone tsars.
>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.
Again, do we mean "identifier" or "name". iCalendar allows the TZNAME property to be repeated any number of times for different display names, in a VTIMEZONE definition.
-- Frank