[tz] [PATCH] Update Crimea country codes in line with UN A/RES/73/263

[Brian Inglis]

On 2021-03-25 20:31, Dimitri John Ledkov via tz wrote:
> On Fri, 26 Mar 2021 at 01:55, Paul Eggert <eggert at cs.ucla.edu> wrote:
>>
>> On 3/25/21 5:46 PM, Dimitri John Ledkov via tz wrote:
>>> I'm not quite sure what it means to have "CZ,SK" dual
>>> code for Europe/Prague.
>>
>> It means that Europe/Prague covers some territory in both CZ (Czech
>> Republic) and SK (Slovakia). This is mentioned in the comments at the
>> start of zone1970.tab.
>>
> 
> I see. In that case it is accurate. Ditto the set of codes for
> Europe/Simferopol that timezone does cover some territory in both RU &
> UA.
> 
>>> is it just an oversight that Europe/Bratislava is not listed in the
>>> zone1970.tab file
>>
>> No, it's intended. The Europe/Bratislava link is present for backward
>> compatibility; it's no longer really needed for tzdb settings since
>> Slovakia's clocks have agreed with Europe/Prague's since 1970.
>>
>>> It would be more helpful to return CS code for
>>> years 1918–1939 and 1945–1992
>>
>> Not really as that wouldn't be historically accurate, and even if it
>> were accurate it would cause more political hassles than we already have
>> (people care a lot about history for some reason :-).
>>
>>> zone1970 is not helpful, especially since it's
>>> alphabetical sort
>>
>> Is this referring to some existing Ubuntu-based software that uses
>> zone.tab and that requires alphabetical sorting? I'd be interested to
>> know what software has this problem. It might be possible to work around
>> problems in this area, but I'd need to know what the problems actually are.
>>
> 
> I think the problem is that it is misused as one-to-one
> territory/boundary mapping, when (a) that's not what it defines (b)
> it's not boundary.
> 
>>> will not yield appropriate country code for
>>> Europe/Simferopol pre/post 2014 time periods
>>
>> That's OK, as zone1970.tab is not a historical database. It's intended
>> only for people who are setting their timezones today.
>>
>>> Are there plans to add a new zone.tab format that provides UNTIL field?
>>
>> No, for the reasons mentioned above.
>>
>> In hindsight the zone.tab file was a mistake because it inspires too
>> many political controversies. zone1970.tab is somewhat better, but even
>> it goes beyond what a timezone database needs to do.
>>
>> These two files were intended only as aids to user interfaces to
>> selecting timezones. Modern timezone-selection user interfaces typically
>> use boundaries[1] rather than these files, so perhaps someday we can
>> remove both of them. Any continuing political controversy about them
>> will likely accelerate the process of their removal.
>>
>> [1] https://data.iana.org/time-zones/tz-link.html#boundaries
> 
> I'll need to double check things, I think we are self-generating
> approximate boundaries based on zone.tab instead of using a
> pre-existing / more accurate boundary map.

I believe that the previously available sources for that information are no 
longer being updated, and time zone sites are using their own approaches, which 
may include outdated data.
Probably better to map gazetteer locations to zones using approximate boundaries 
or older data, and tweak any discrepancies.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in binary units and prefixes, physical quantities in SI.]