Timezone in Autonomous Republic of Crimea and spelling of Kyiv
*Dear Mr. Paul Eggert,* By this letter let me as the representative of Ukraine to ICANN's GAC inform you about the following. The State Agency for e-Governance of Ukraine is the national authority of Ukraine that is responsible for matters related to Internet governance, including those within the purview of ICANN. We have discovered mistakes in the Time Zone Database. In particular, the time zones, country code and coordinates for the part of Ukrainian territory, namely the Autonomous Republic of Crimea, the city of Simferopol, and Sevastopol, are determined incorrectly. As far as we are aware, the Zone Europe/Simferopol was changed to MSK on the grounds of Russian Federation citizen appeal (Mr. Alexander Krivenyshev). The appeal was filed after *Russian military intervention in Autonomous Republic of Crimea followed by the illegal annexation of the sovereign territory of Ukraine.* We would request your immediate attention that change of this specified time zone is *a gross violation of the rules of international law*, namely: - United Nations General Assembly Resolution 68/262, adopted on March 27, 2014 by the sixty-eighth session of the United Nations General Assembly in response to the Russian annexation of Crimea, entitled "Territorial integrity of Ukraine"; - United Nations General Assembly Resolutions 71/205, 72/190, 73/263: Situation of human rights in the Autonomous Republic of Crimea and the city of Sevastopol (Ukraine); - United Nations General Assembly Resolution 73/194: Problem of the militarization of the Autonomous Republic of Crimea and the city of Sevastopol, Ukraine, as well as parts of the Black Sea and the Sea of Azov. Taking into account the above, we urge you to resolve this situation by determining *EU EE%sT time for Zone Europe/Simferopol* in Time Zone Database and identify* UA* as a country code for *Europe/Simferopol.* At the same time, we draw your attention to the decision of The United States Board on Geographic Names. *English spelling of Ukraine’s capital has changed from Kiev to Kyiv* (source: https://www.kyivpost.com/world/kyiv-not-kiev-us-changes-spelling-of-ukrainia...). In this regard, we ask you to update the spelling of Kyiv in all existing databases of your organization. ---------------------------------------------- *Sincerely,Oleksandr RyzhenkoHead of the State Agency for e-Governance of UkraineRepresentative of Ukraine to ICANN’s GAC *
On 6/21/19 10:17 AM, Oleksandr Ryzhenko wrote:
We would request your immediate attention It is getting that attention. You cc'ed your message to Serhii Demediuk, and the matter is being discussed in the following email thread with him:
https://mm.icann.org/pipermail/tz/2018-December/027303.html https://mm.icann.org/pipermail/tz/2018-December/027304.html https://mm.icann.org/pipermail/tz/2018-December/027305.html I proposed a patch that I hoped would address his concerns, here: https://mm.icann.org/pipermail/tz/2018-December/027306.html with no reply. Yesterday I pinged him again: https://mm.icann.org/pipermail/tz/2019-June/028176.html with no reply yet.
On 2019-06-21 11:17, Oleksandr Ryzhenko wrote:
By this letter let me as the representative of Ukraine to ICANN's GAC inform you about the following. The State Agency for e-Governance of Ukraine is the national authority of Ukraine that is responsible for matters related to Internet governance, including those within the purview of ICANN.
As an ICANN GAC representative you should be aware that RFC 6557 BCP 175 Procedures for Maintaining the Time Zone Database documents the process, be familiar with its contents, and follow the ICANN, IANA, and IETF processes to point out where the time zone database contents have not been maintained in conformance with that Best Current Practice, or discuss in what ways that Best Current Practice should be modified to allow the database to better reflect the reality of time zone offsets used in time zones. The time zone data reflects the reality of time being kept in a zone during a historical period, labelled by English language ASCII technical directory and file zone identifiers, which for human convenience may correspond to the most commonly used historical English language identifiers of representative geographic entities such as continents, oceans, regions, countries, territories, or cities, and similarly for English language ASCII technical abbreviations used after times to label zones where there could be ambiguity in observance or interpretation. Note that nowhere are zones defined they are only identified by labels. Political disputes about identifiers and labels are really *OFF TOPIC* for this list, and should be kept for more appropriate forums. As such, political considerations and resolutions by the UN, EU, US, etc. have no bearing on the contents of the technical time zone data base, except in so far as UTC offsets of time observed on the ground in a zone, are legislated and modified by political actions, including territorial disputes including war. Some historical data has been corrected to reflect the reality of actual time keeping in zones during territorial disputes and war times. Most of the disputed information is provided solely for the information and convenience of humans in downstream projects and organizations. It is up to downstream projects, applications, systems, distros, organizations, and vendors which use the data to provide what they consider suitable localizations in their interfaces which use the time zone data. Perhaps this would be a good time to reduce the dispute surface by removing all country codes, all compatibility links, and all English time zone abbreviations, from all time zone data files, generating POSIX %z abbreviations. Consideration should also be given to reducing the identifiers to arbitrary numbered file names: zoneinfo/01-99/0001-9999, where the directory corresponds to the continent/ocean/region after renaming as numbered data files, and the zone identifier corresponds to the sequential order of the zone in each numbered data file. To accommodate this, null zone entries would have to be allowed to handle splits or merges where historical information changes. For completeness, rule identifiers should also be replaced by sequential numbers within each data file, and to accomodate historical information changes, null rule entries would have to be allowed to handle splits or merges. Historical English language ASCII identifiers and labels could possibly be maintained in the personal experimental github repository, which could contain scripts to sanitize the data supplied to IANA. To avoid any possibility of disputes, comments could also be stripped. If maintaining those historical identifiers, labels, and comments is not considered desirable, mappings between the time zone identifiers and geographic locations would be the sole responsibility of downstream consumers. Alternatively, as time zone data is binary system information essentially unrelated to the Internet, and the IANA connection seems to be increasing the irrelevant disputes and politicking on the list, find an alternate host for the list and the database, perhaps in the non-GNU sections of the GNU organization, or somewhere more neutral, such as an open source organization or site in Scandinavia or elsewhere. -- 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.
On 2019-06-22 01:39:36 (+0530), Brian Inglis wrote:
Perhaps this would be a good time to reduce the dispute surface by removing all country codes, all compatibility links, and all English time zone abbreviations, from all time zone data files, generating POSIX %z abbreviations.
...thus making the tz database impossible (or at least substantially more difficult) to maintain and understand.
Alternatively, as time zone data is binary system information essentially unrelated to the Internet, and the IANA connection seems to be increasing the irrelevant disputes and politicking on the list, find an alternate host for the list and the database, perhaps in the non-GNU sections of the GNU organization, or somewhere more neutral, such as an open source organization or site in Scandinavia or elsewhere.
Or simply continue to point one-off politically motivated contributors to the tz mailing list to the conventions and policy documents and let the threads die out quickly. I like Paul's constructive approach to these discussions and admire his patience! Philip -- Philip Paeps Senior Reality Engineer Alternative Enterprises
I find it difficult to be sure that I am following the nature of the requests being presented to the mail list. Too many messages not containing patches ask for things which are not part of tzdb. Much content other than patches (including my own message here) is just noise. For complete and prompt consideration requests should include suggestions in the form of patches to a specific tz version in order to communicate the file name(s) and desired changes to line(s) of those file(s). -- Steve Allen <sla@ucolick.org> WGS-84 (GPS) UCO/Lick Observatory--ISB 260 Natural Sciences II, Room 165 Lat +36.99855 1156 High Street Voice: +1 831 459 3046 Lng -122.06015 Santa Cruz, CA 95064 https://www.ucolick.org/~sla/ Hgt +250 m
On Fri, 2019-06-21 at 14:09 -0600, Brian Inglis wrote:
Perhaps this would be a good time to reduce the dispute surface by removing all country codes, all compatibility links, and all English time zone abbreviations, from all time zone data files, generating POSIX %z abbreviations.
This rather reminds me of the archtypical Dutch farmer in American colonial times who burned down his own barn in order to rid it of rats. Cheers! |---------------------------------------------------------------------| | Frederick F. Gleason, Jr. | Chief Developer | | | Paravel Systems | |---------------------------------------------------------------------| | My name means the shape I am! (Humpty Dumpty) | | | | -- Lewis Carroll | | "Through the Looking Glass" | |---------------------------------------------------------------------|
On Jun 21, 2019, at 4:43 PM, Fred Gleason <fredg@paravelsystems.com> wrote:
[EXTERNAL EMAIL]
On Fri, 2019-06-21 at 14:09 -0600, Brian Inglis wrote:
Perhaps this would be a good time to reduce the dispute surface by removing all country codes, all compatibility links, and all English time zone abbreviations, from all time zone data files, generating POSIX %z abbreviations.
This rather reminds me of the archtypical Dutch farmer in American colonial times who burned down his own barn in order to rid it of rats.
Cheers!
Another consideration is whether it would actually help. Part of the political issue is the name attached to the region in question. But another part is what the rule is for a region such as Crimea. I think that changing the zone name to 314159 wouldn't cure the problem that the actual numbers (the offsets and/or summer time rules) are "wrong" by some definitions. paul
On 2019-06-21 14:48, Paul Koning wrote:
On Jun 21, 2019, at 4:43 PM, Fred Gleason wrote: On Fri, 2019-06-21 at 14:09 -0600, Brian Inglis wrote:
Perhaps this would be a good time to reduce the dispute surface by removing all country codes, all compatibility links, and all English time zone abbreviations, from all time zone data files, generating POSIX %z abbreviations. This rather reminds me of the archtypical Dutch farmer in American colonial times who burned down his own barn in order to rid it of rats. Another consideration is whether it would actually help. Part of the political issue is the name attached to the region in question. But another part is what the rule is for a region such as Crimea. I think that changing the zone name to 314159 wouldn't cure the problem that the actual numbers (the offsets and/or summer time rules) are "wrong" by some definitions. They or their interface are choosing the wrong zone 06/0040 instead of 06/0072: no Europe, Simferopol, or Kiev to bother about!
-- 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.
On Fri, 2019-06-21 at 15:33 -0600, Brian Inglis wrote:
They or their interface are choosing the wrong zone 06/0040 instead of 06/0072: no Europe, Simferopol, or Kiev to bother about!
Sure! But let's not lose sight of the benefits, in terms of ease of database maintenance, that those 'real world' identifiers bring as well. Getting rid of them in tzdb really solves nothing, but merely makes it Someone Else's Problem while increasing the overall global complexity of the system. Keeping the current identifiers sounds like a pretty good tradeoff to me if the only cost is having to educate the occasional under-informed person who raises the issue. Most of the ones I've observed here have proven to be very understanding once the relevant parts of 'theory.html' have been pointed out to them. Cheers! |---------------------------------------------------------------------| | Frederick F. Gleason, Jr. | Chief Developer | | | Paravel Systems | |---------------------------------------------------------------------| | Politics is like coaching a football team. You have to be smart | | enough to understand the game but not smart enough to lose | | interest. | | | | -- Anonymous | |---------------------------------------------------------------------|
Dear Oleksandr, We indeed raised this issue in December. Unfortunately, our proposal have not been accepted. We provided additional reasons and historical analogues to support our proposal, but only achieved partial understanding. For us, non-native speakers, Paul's last email was very clear that he already made final decision and plan to sitisfy our proposal only partially, still leaving Crimea associated with the Russia in one of the TZDB files. It was not exactly our proposal, and for obvious reasons I was not in a position to accept it and choose 'lesser of evils'. It is a big surprise to discover that 6 months later this public discussion is used to repeatedly blame us for the fact that even 'partial' patch, which was prepared in December is still not implemented due to the lack of attention from my side. As you may see, there is no any word in Paul's last email in December, which would suggest that there is any reply expected from our side in order to implement that patch. Dear Paul, I take this opportunity to beg my pardon for misunderstanding, which prevented you from implementation of your own decision due to the lack of attention from my side. I'd like to make clear that we cannot fully support proposed patch, but we fully respect your authority and respect your decisions, even the ones, which made without our agreement. I sincerely believe that case is clear and acceptance of Russian occupation for 'practicality reasons' is not an option which I personally would ever support. Please, do not blame me for the lack of flexibility, but our proposal was formulated in December and remains the same. Your position is also clear. You have authority to implement the patch, which was prepared in December, if you feel that it is properly addressing this issue. There is no need to blame others for the fact that it is not implemented in TZDB. Sorry for not responding to your yesterday's email immediately, but since I'm on leave and have only accasional opportunity to check emails - my replys are slightly delayed. Kind regards, Head of the Cyberpolice Department of the National Police of Ukraine Serhii Demediuk tel.: +380443743738 e-mail: serhii.demediuk@cyberpolice.gov.ua Ukraine, Kyiv
21 июня 2019 г., в 20:17, Oleksandr Ryzhenko <gacryzhenko@gmail.com> написал(а):
Dear Mr. Paul Eggert,
By this letter let me as the representative of Ukraine to ICANN's GAC inform you about the following. The State Agency for e-Governance of Ukraine is the national authority of Ukraine that is responsible for matters related to Internet governance, including those within the purview of ICANN.
We have discovered mistakes in the Time Zone Database. In particular, the time zones, country code and coordinates for the part of Ukrainian territory, namely the Autonomous Republic of Crimea, the city of Simferopol, and Sevastopol, are determined incorrectly. As far as we are aware, the Zone Europe/Simferopol was changed to MSK on the grounds of Russian Federation citizen appeal (Mr. Alexander Krivenyshev). The appeal was filed after Russian military intervention in Autonomous Republic of Crimea followed by the illegal annexation of the sovereign territory of Ukraine.
We would request your immediate attention that change of this specified time zone is a gross violation of the rules of international law, namely:
- United Nations General Assembly Resolution 68/262, adopted on March 27, 2014 by the sixty-eighth session of the United Nations General Assembly in response to the Russian annexation of Crimea, entitled "Territorial integrity of Ukraine";
- United Nations General Assembly Resolutions 71/205, 72/190, 73/263: Situation of human rights in the Autonomous Republic of Crimea and the city of Sevastopol (Ukraine);
- United Nations General Assembly Resolution 73/194: Problem of the militarization of the Autonomous Republic of Crimea and the city of Sevastopol, Ukraine, as well as parts of the Black Sea and the Sea of Azov.
Taking into account the above, we urge you to resolve this situation by determining EU EE%sT time for Zone Europe/Simferopol in Time Zone Database and identify UA as a country code for Europe/Simferopol.
At the same time, we draw your attention to the decision of The United States Board on Geographic Names. English spelling of Ukraine’s capital has changed from Kiev to Kyiv (source: https://www.kyivpost.com/world/kyiv-not-kiev-us-changes-spelling-of-ukrainia...). In this regard, we ask you to update the spelling of Kyiv in all existing databases of your organization.
---------------------------------------------- Sincerely, Oleksandr Ryzhenko Head of the State Agency for e-Governance of Ukraine Representative of Ukraine to ICANN’s GAC <2019_06_21_10_00_16.pdf>
serhii.demediuk@cyberpolice.gov.ua wrote:
For us, non-native speakers, Paul's last email was very clear that he already made final decision
Thanks for your response. I apologize that my email <https://mm.icann.org/pipermail/tz/2018-December/027306.html> gave you that misimpression. That email's last sentence was intended to indicate that the proposal was tentative and not final. However, as nobody has since come up with anything better under the constraints of the tzdb format, I just now merged the proposed patch into the developmental version on Github <https://github.com/eggert/tz>, so this patch is now planned to appear in the next tzdb release. The merged patch is attached for reference. Although I don't expect this to make everybody happy (certainly I'm not happy about the situation), the patch does appear to be an improvement.
On 2019-06-22 19:50, Paul Eggert proposed the patch:
+# The obsolescent zone.tab format cannot represent Europe/Simferopol well. +# Put it in RU section and list as UA.
This would invalidate the invariant used hitherto for "zone.tab": The single country code chosen for a location in "zone.tab" (and used as the first country code for a location in "zone1970.tab") designates the administration hierarchy that currently effectively determines the civil time at the location (except for AQ). Michael Deckers.
Michael Deckers via tz wrote:
This would invalidate the invariant used hitherto for "zone.tab":
The single country code chosen for a location in "zone.tab" (and used as the first country code for a location in "zone1970.tab") designates the administration hierarchy that currently effectively determines the civil time at the location (except for AQ).
That invariant is not documented in tzdb, and it's incorrect for areas other than AQ and Crimea. For example, "US" identifies the administration hierarchy that currently effectively determines the the civil time for Guam, but zone.tab doesn't put Pacific/Guam under "US". Anyway, I'd rather not add political restrictions like that to the data or to the documentation. We already have too much politics in tzdb already, and we should be working to remove rather than add political constraints.
participants (9)
-
Brian Inglis -
Fred Gleason -
Michael Deckers -
Oleksandr Ryzhenko -
Paul Eggert -
Paul.Koning＠dell.com -
Philip Paeps -
serhii.demediuk＠cyberpolice.gov.ua -
Steve Allen