[tz] State of the tzdb

[Norbert Lindenberg]

On Sep 3, 2013, at 13:38 , Guy Harris <guy at alum.mit.edu> wrote:

> On Sep 3, 2013, at 3:00 AM, Stephen Colebourne <scolebourne at joda.org> wrote:
> 
>> 4) Recognise correct usage of "backward" file
>> As per ECMAscript:
>> http://norbertlindenberg.com/ecmascript/intl.html#sec-6.4.2
>> the "backward" is, and will continue to be, used for canonicalization
>> - ie. identifying which IDs can be normalized away.
> 
> I presume
> 
> 	If ianaTimeZone is a Link name, then let ianaTimeZone be the corresponding Zone name as specified in the “backward” file of the IANA Time Zone Database.
> 
> was intended to either to be
> 
> 	If ianaTimeZone is a Link name *that appears in the “backward” file of the IANA Time Zone Database*, then let ianaTimeZone be the corresponding Zone name as specified in that file.
> 
> or to be
> 
> 	If ianaTimeZone is a Link name, then let ianaTimeZone be the corresponding Zone name as specified in whichever file of the IANA Time Zone Database specifies the Link name.
> 
> because there are Link names that *don't* appear in the "backward" file.  (I've sent a message to Norbert to that effect.)
> 
> With the first of those formulations, Europe/Zagreb would *not* get canonicalized to Europe/Belgrade, and Europe/Istanbul would *not* get canonicalized to Asia/Istanbul, for example.
> 
> With the second of those formulations, *both* of those canonicalizations would occur.
> 
> My guess is that the first of those formulations was intended, i.e. that two Linked-together tzids are to be thought of as separate tzids (that happen to share GMT offsets etc.) unless the Link line is in the "backwards" file.

Thanks for the feedback - this is a bug in the spec. The intent was the second - to treat all Zone names as canonical names and all Link names as aliases. The mistake was in the assumption that all Link entries are contained in the "backward" file. I've filed a bug report.

Norbert