Frank_Dawson@xxxxxxxxx wrote: > > >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. 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. > 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). 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. > > >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. 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? > >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. 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. > >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. 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
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature