Frank_Dawson@xxxxxxxxx wrote: > > Doug (and David): > > I don't see that there is a problem with having numerous definitions > for time zones with a different TZID or TZNAME but with the same time > zone information. I agree with you "over the wire". I was thinking of IANA registration overhead. If one changes - how do the IANA people know they are "THE SAME" as another? Unless we have some out of band information? > > Time zones, by nature, are under local governmental control. If there > are two or more locals at the same UTC offset, then they would fall > under this case. I agree - Not the issue. US/Pacific is simply an old name for America/Los_Angeles. So it is NOT that I was asking for all gmt-offset values that have the same offset to be the same name. I was asking what do we do with the historical names? > A given time zone may have had its definition changed over time. This > would account for multiple definitions for the same time zone, also. Yes - those are easy. If the name is different - we register its different name. Each with there own unique data. > Likewise, the duplicate definitions could result from a change in the > name or identifier of one or more of these time zone definitions. Exactly the question! So how do we specify that XX == YY and only the name has changed? Using VTIMEZONE restrictions as defined by the IETF docs? > In any case, our role is merely to capture all the definitions in a common > format. Not to become time zone tsars and redefine the time zone > definitions, names or whatever. Right? We do NOT want to be the czar of timezones! We do want clients to be able to use existing and historical names to be able to understand and communicate iCalendar/VTIMEZONE data. -Doug
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature