Subject: Re: VTIMEZONE and signular TZID

From: [email-masked]
Date: Wed, 19 Apr 2000 12:05:57 -0400

Doug Royer wrote, in part:
>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

---

From: Doug Royer <[email-masked]>
Date: Wed, 19 Apr 2000 12:01:31 -0700

[email-masked] wrote:
> 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.

Yes - but in the Olson database they have what they call 'Link's.
And that allows them to define that (in iCal terms) TZID:1 == TZID:2 .

TZNAME is(for example) PDT and PST, and they also have that in Olson
(Olson-Format + Olson-Letter/s). Those can overlap and are only used
to aid clients to format the data on the screen. TZNAMEs are not the
IANA registered names described by tzid (tzidprefix) in RFC2445.

> 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).

Olson keeps both names (where both can be > 2) . I was trying to figure
out how to keep both names.

> May be some of the apparent cases of an "alias" are actually intended to be
> different time zone definitions. ...

No - in the Olson database they are simply alternate names for the
same data.

> 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.

Because in the Olson data base if I update America/Los_Angeles,
then I am also updating US/Pacific. 

If we register them separately - they IANA will have to track
that they are the same. And whenever one is updated, they
will have to update the other. For how long? How will they know
to do this? What if one gets out of sync with the other - which
one is correct?

> 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.

True - but not the same question.

What if xyz country decides to call the 'US/Pacific' timezone 'WestOfUs'
because that is what they call the US/Pacific timezone in their
country. Do we just keep adding aliases? Maybe.

> property to be repeated any number of times for different display names, in a
> VTIMEZONE definition.

Yes we do - the question was not TZNAME - it was TZID.

We could add the data in TZNAME. Someone else commented on
that. However TZNAME only goes in daylightc or standardc.
So where does US/Pacific go - in daylightc or standardc?

We (so far) do not allow more that one identifier for each
set of time zone data.

-Doug