[PATCH] Update Crimea country codes in line with UN A/RES/73/263
"the Autonomous Republic of Crimea and the city of Sevastopol, Ukraine, temporarily occupied by the Russian Federation" is the preffered way to refer to the Crimean Peninsula as called upon by the A/RES/73/263 point 11. [1] Unfortunately there is no two letter country code to state precisely that. For internet & computer users however whenever any locale & location is derived from the zone.tab & zone1970.tab file formats results in most appropriate UX with a temporary RU country code. [1] https://www.un.org/en/ga/search/view_doc.asp?symbol=A/RES/73/263 Note, that it is best read in conjuction with resolutions from previous and subsequent sessions. I.e. https://www.un.org/en/ga/search/view_doc.asp?symbol=A/RES/68/262 https://www.un.org/en/ga/search/view_doc.asp?symbol=A/RES/71/205 https://www.un.org/en/ga/search/view_doc.asp?symbol=A/RES/72/190 https://www.un.org/en/ga/search/view_doc.asp?symbol=A/RES/73/194 https://www.un.org/en/ga/search/view_doc.asp?symbol=A/RES/73/263 https://www.un.org/en/ga/search/view_doc.asp?symbol=A/RES/74/17 https://www.un.org/en/ga/search/view_doc.asp?symbol=A/RES/75/29 Signed-off-by: Dimitri John Ledkov <xnox@ubuntu.com> --- Users from the Crimean Pensinsula are reporting issues when using computer systems. Many pieces of software derive and display location/country based on the zone.tab file format which doesn't reflect the widely internationally acknowledged (as ratified by UN general assembly resolutions) temporary occupation of the pensinsula by the Russian Federation. Currently, the currency in use is rubles; telephone country codes switch to +7, with old ones defunct; MasterCard/Visa networks replaced by MIR network; car license plates are issues with Russian area codes; local government *.gov.ua websites are defunct, replaced with *.gov.ru, e.g. https://sev.gov.ua/ => https://sev.gov.ru/; and so on. As this issue is causing distress to the users of the Internet, I hope that this proposed temporary updated could be included in the tzdata update. zone.tab | 8 ++++---- zone1970.tab | 6 ++++-- 2 files changed, 8 insertions(+), 6 deletions(-) diff --git a/zone.tab b/zone.tab index 14fceb9..35e2493 100644 --- a/zone.tab +++ b/zone.tab @@ -331,10 +331,10 @@ RO +4426+02606 Europe/Bucharest RS +4450+02030 Europe/Belgrade RU +5443+02030 Europe/Kaliningrad MSK-01 - Kaliningrad RU +554521+0373704 Europe/Moscow MSK+00 - Moscow area -# The obsolescent zone.tab format cannot represent Europe/Simferopol well. -# Put it in RU section and list as UA. See "territorial claims" above. -# Programs should use zone1970.tab instead; see above. -UA +4457+03406 Europe/Simferopol Crimea +# "the Autonomous Republic of Crimea and the city of Sevastopol, Ukraine, +# temporarily occupied by the Russian Federation" +# Temporarily list as RU. See "territorial claims" above. +RU +4457+03406 Europe/Simferopol Crimea RU +5836+04939 Europe/Kirov MSK+00 - Kirov RU +4844+04425 Europe/Volgograd MSK+00 - Volgograd RU +4621+04803 Europe/Astrakhan MSK+01 - Astrakhan diff --git a/zone1970.tab b/zone1970.tab index ddb2321..d699388 100644 --- a/zone1970.tab +++ b/zone1970.tab @@ -288,8 +288,10 @@ RO +4426+02606 Europe/Bucharest RS,BA,HR,ME,MK,SI +4450+02030 Europe/Belgrade RU +5443+02030 Europe/Kaliningrad MSK-01 - Kaliningrad RU +554521+0373704 Europe/Moscow MSK+00 - Moscow area -# Mention RU and UA alphabetically. See "territorial claims" above. -RU,UA +4457+03406 Europe/Simferopol Crimea +# "the Autonomous Republic of Crimea and the city of Sevastopol, Ukraine, +# temporarily occupied by the Russian Federation" +# Temporarily list as RU. See "territorial claims" above. +RU +4457+03406 Europe/Simferopol Crimea RU +5836+04939 Europe/Kirov MSK+00 - Kirov RU +4844+04425 Europe/Volgograd MSK+00 - Volgograd RU +4621+04803 Europe/Astrakhan MSK+01 - Astrakhan -- 2.27.0
The underlying problem here is any Ubuntu-based software that is still using the long-obsolescent zone.tab file, or that cannot handle more than one country code in column 1 of the zone1970.tab file. You didn't mention what software was involved, but whatever it is I suggest fixing it so that your users' problems go away. Any zone.tab-reading software should be upgraded anyway (zone.tab has been obsolescent since tzdb 2014f), and you can use this Crimea issue to motivate any stragglers. Alternatively, you could install the patch that you proposed into Ubuntu downstream, and the Ubuntu developers could then deal with this political dispute's fallout in an Ubuntu-specific way. Your call.
Hi, On Fri, 26 Mar 2021 at 00:09, Paul Eggert <eggert@cs.ucla.edu> wrote:
The underlying problem here is any Ubuntu-based software that is still using the long-obsolescent zone.tab file, or that cannot handle more than one country code in column 1 of the zone1970.tab file. You didn't mention what software was involved, but whatever it is I suggest fixing it so that your users' problems go away. Any zone.tab-reading software should be upgraded anyway (zone.tab has been obsolescent since tzdb 2014f), and you can use this Crimea issue to motivate any stragglers.
Alternatively, you could install the patch that you proposed into Ubuntu downstream, and the Ubuntu developers could then deal with this political dispute's fallout in an Ubuntu-specific way. Your call.
The zone1970.tab file format feels incomplete to me. Unlike the zone file format (i.e. "europe"). It feels that it lacks the "UNTIL" field, as which country codes apply change from time to time. For example, I'm not quite sure what it means to have "CZ,SK" dual code for Europe/Prague. It would be more helpful to return CS code for years 1918–1939 and 1945–1992, and return only CZ from 1993 onwards. SK code doesn't quite make sense - despite the fact that Europe/Bratislava is linked to Europe/Prague it would be best to have separate entries for Europe/Bratislava returning SK & CS codes based on time. Or is it just an oversight that Europe/Bratislava is not listed in the zone1970.tab file, whilst present in the zone.tab file? Suggestion to just use zone1970 is not helpful, especially since it's alphabetical sort and will not yield appropriate country code for Europe/Simferopol pre/post 2014 time periods, and a future period that will change the predominant code. Are there plans to add a new zone.tab format that provides UNTIL field? It would be immensely helpful if there was a top level ISO 3166 two letter code for Crimean Peninsula. As that would be quite a neutral way to precisely identify the region which at the moment stands a test of time. I am writing to the ISO 3166 Maintenance Agency about that separately. -- Regards, Dimitri.
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.
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.
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
On Fri, 26 Mar 2021 at 01:55, Paul Eggert <eggert@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. -- Regards, Dimitri.
On 2021-03-25 20:31, Dimitri John Ledkov via tz wrote:
On Fri, 26 Mar 2021 at 01:55, Paul Eggert <eggert@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.]
participants (3)
-
Brian Inglis -
Dimitri John Ledkov -
Paul Eggert