- tz - lists.iana.org

*Off topic* A little respect ...
by Chris Woodbury June 25, 2019

June 25, 2019

> On Sun Jun 23 08:57:16 UTC 2019 Sergij Marchenko makars at gmail.com wrote: > > You write very beautifully, but the fact remains that once the Russians > occupy the Crimea, you immediately made changes, pleasing Putin ... Yes, I suppose that might have pleased Putin (if he ever became aware of it if only by the fact that his cellular telephone showed the correct local time) but ... it wasn't done to please or displease him or his cronies (and the fifth columnists 'phones are right, too.) It was, as has been explained, to reflect the technical "reality on the ground". I'm sorry if that displeased you but it is what it is. Being obstreperous isn't going to change anything (except by further expanding the misery). Making us out to be tools of injustice doesn't make it so. Note that the *country codes* that came into question have been patched reasonably expeditiously by Dr. Eggert. TZ will reflect reality as best it can under the circumstances with or without anyone's complete satisfaction. I *am* certain that no one is happy about all the death, destruction and heart wrenching circumstances from what has come to pass. My thoughts and prayers are with all the people who find themselves in such unfortunate conditions. Were it only within my power to change them....

6 5

Jeopardy! category on time zones 2019-05-28
by Tim Parenti June 24, 2019

June 24, 2019

Apparently there is a category on time zones on the US version of *Jeopardy!* tonight (Tuesday 28 May). I'll avoid any spoilers for now — due to the vagaries of US broadcast syndication and, well, time zones — for anyone stateside who might be as captivated by the performance of the current champion, James Holzhauer, as my friends. I'll try to send over the clues tomorrow. -- Tim Parenti

1 1

Timezone in Autonomous Republic of Crimea and spelling of Kyiv
by Oleksandr Ryzhenko June 23, 2019

June 23, 2019

*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-ukraini…) 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 *

9 12

*Off topic* A little respect ...
by Chris Woodbury June 23, 2019

June 23, 2019

To Oleksandr Ryzhenko, et al, and whom so ever might be listening: Firstly, that's Dr. Paul R. Eggert, PhD 1980 UCLA. He has been voluntarily contributing his time to this (and other) projects (and education) for over thirty years. I, for one, respect and value his contributions (even when I momentarily forget to do so). Secondly, telling us (and him) that such and such is a violation of "*international law*" (as tho they were an authority and someone was going to be dragged off to the The Hague) is a threat and an inappropriate response to the supposed provocation. Making such is a clear indication that there is a certain lack of understanding of what's really going on. (As an aside and for what it's worth: I commiserate with those worrying about the whole Kiev/Kyiv thing. It's a huge "can of worms" and technical but it ain't going to happen! If it were "fixed" this one time, a precedent would be set and similar "problems" would have to be "fixed". It would be never ending. Theresult being *technically unnecessary* database "churn". The stance that some-thing like this are internal labels is an interesting solution to a "problem". Also, thinking of them as a thing imposed over the barrel of a gun and wanting to "fix it" *right now*, where others might not, is just going to raise ones blood pressure. It will be changed sometime. The language or transliteration will change over time, or there will be new generation of tzdb volunteer maintainers (hint, hint) or, possibly, our own version of Vasili Arkhipov* will come along and find a solution. Remember, sometimes a "problem" is merely a matter of perspective. (I was also raised to appreciate an excellent quibble when I see one.)) (Also, I might be wrong, but one might consider that treating the TZ database as if it were a legal document could be a mistake.) Lastly, I personally would appreciate it if the folks "who have a bone to pick" would spend the same amount of time they spend so carefully crafting their e-mails*going over the content of the archives* before they actually send them. It also might be helpful to *consult a subject matter expert* while composing, too. It might just save some time for all of us. * An underappreciated man who saved the world. -

2 1

[PATCH] Fix ‘make check’ problems caused by recent changes
by Paul Eggert June 22, 2019

June 22, 2019

* Makefile: Fix stray non-ASCII chars in comments. (check_sorted): Omit tests that duplicate what checktab.awk does. Discovered when debugging checktab.awk. * checktab.awk: Don’t complain about special case for Crimea. --- Makefile | 10 ++-------- checktab.awk | 9 ++++++++- 2 files changed, 10 insertions(+), 9 deletions(-) diff --git a/Makefile b/Makefile index d305f68..6816d3b 100644 --- a/Makefile +++ b/Makefile @@ -36,7 +36,7 @@ DATAFORM= main LOCALTIME= GMT # The POSIXRULES macro controls interpretation of nonstandard and obsolete -# POSIX-like TZ settings like TZ=’EET-2EEST’ that lack DST transition rules. +# POSIX-like TZ settings like TZ='EET-2EEST' that lack DST transition rules. # In the reference implementation, if you want something other than Eastern # United States time as a template for handling these settings, you can # change the line below (after finding the timezone you want in the @@ -58,7 +58,7 @@ LOCALTIME= GMT # Nonempty POSIXRULES is obsolete and should not be relied on, because: # * It does not work correctly in popular implementations such as GNU/Linux. # * It does not work in the tzdb implementation for timestamps after 2037. -# * It is incompatible with ’zic -b slim’ if POSIXRULES specifies transitions +# * It is incompatible with 'zic -b slim' if POSIXRULES specifies transitions # at standard time or UT rather than at local time. # In short, software should avoid ruleless settings like TZ='EET-2EEST' # and so should not depend on the value of POSIXRULES. @@ -805,12 +805,6 @@ CHECK_CC_LIST = { n = split($$1,a,/,/); for (i=2; i<=n; i++) print a[1], a[i]; } check_sorted: backward backzone iso3166.tab zone.tab zone1970.tab $(AWK) '/^Link/ {print $$3}' backward | LC_ALL=C sort -cu $(AWK) '/^Zone/ {print $$2}' backzone | LC_ALL=C sort -cu - $(AWK) '/^[^#]/ {print $$1}' iso3166.tab | LC_ALL=C sort -cu - $(AWK) '/^[^#]/ {print $$1}' zone.tab | LC_ALL=C sort -c - $(AWK) '/^[^#]/ {print substr($$0, 1, 2)}' zone1970.tab | \ - LC_ALL=C sort -c - $(AWK) '/^[^#]/ $(CHECK_CC_LIST)' zone1970.tab | \ - LC_ALL=C sort -cu touch $@ check_links: checklinks.awk $(TDATA_TO_CHECK) tzdata.zi diff --git a/checktab.awk b/checktab.awk index 393ab19..ec145b5 100644 --- a/checktab.awk +++ b/checktab.awk @@ -63,12 +63,19 @@ BEGIN { coordinates = $2 tz = $3 comments = $4 - if (cc < cc0) { + + # Don't complain about a special case for Crimea in zone.tab. + # FIXME: zone.tab should be removed, since it is obsolete. + # Or at least put just "XX" in its country-code column. + if (cc < cc0 \ + && !(zone_table == "zone.tab" \ + && tz0 == "Europe/Simferopol")) { printf "%s:%d: country code '%s' is out of order\n", \ zone_table, zone_NR, cc >>"/dev/stderr" status = 1 } cc0 = cc + tz0 = tz tztab[tz] = 1 tz2comments[tz] = comments tz2NR[tz] = zone_NR -- 2.21.0

1 0

Re: [tz] Crimean timezones
by Sergij Marchenko June 21, 2019

June 21, 2019

Dear Paul, By making such a proposal to Mr. Demediuk you are in fact taking sides despite your alleged neutrality. Russia's claims to Crimea are not supported by anyone but Russia itself, perhaps barring a negligible amount of countries that have their own governments largely criticized as undemocratic. The vast majority of countries have openly condemned the annexation and Russian aggression and continue to recognize Crimea as a Ukrainian territory it is. A solution, which is more consistent with your view, exists. The patch could instead make the interface display the timezones in question as Russian to Russian users alone, while in the rest of the world they would be listed as Ukrainian. This practice, although controversial in the face of the international law, is a lesser violation of it than the current state of matter. By keeping things the way they are now you are sending the world a message. The message is that you are endorsing the aggressor, even though it may not appear to you as such. With a leaden heart we would accept the territory being assigned to different countries depending on a user's geolocation, provided that RU only shows up for Russian users and UA is the default configuration elsewhere, globally. Otherwise we would kindly ask you to drop the neutrality claims and make your open endorsement of Russian military aggression against Ukraine transparent. Kind regards. -- Best regards, Sergij Marchenko mailto:makars@gmail.com http://makar.homelinux.net Skype: makarsoft Viber/WhatsApp/Telegram/Signal: +380661877234

3 2

Re: [tz] Crimean timezones
by Sergij Marchenko June 21, 2019

June 21, 2019

I'm using Fedora release 30 (Thirty) 5.1.11-300.fc30.x86_64 Here is a screenshot in the Gnome-3 environment: http://makar.homelinux.net/ftp/pub/exchange/20190621/Screenshot_20190620_14… When selecting the city Simferopol highlights the Russian Federation (and in fact, correctly - Ukraine) Here is a screenshot in KDE: http://makar.homelinux.net/ftp/pub/exchange/20190621/Screenshot_20190620_21… When choosing a city, Simferopol highlights Europe / Russia (and in fact, rightly, Europe / Ukraine) -- Best regards, Sergij Marchenko mailto:makars@gmail.com http://makar.homelinux.net Skype: makarsoft Viber/WhatsApp/Telegram/Signal: +380661877234

1 0

Timezone in Autonomous Republic of Crimea and spelling of Kyiv
by Oleksandr Ryzhenko June 21, 2019

June 21, 2019

*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-ukraini…) 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*

1 0

Crimean timezones
by Sergij Marchenko June 20, 2019

June 20, 2019

Dear Mr. Eggert, I am reaching out to you as to the IESG-designated TZ Coordinator, as you are listed here: https://www.iana.org/time-zones Let me preface my letter with assuring you that I am reaching out in good will. I live in Ukraine. As a longtime Linux user, I was disappointed to notice that in my timezone settings that one of Simferopol is being assigned to the Russian Federation. Apparently, my preferred desktop environment, along with several others, pulls this data from the project you maintain. The statement that Simferopol (or Sevastopol, or any other Crimean city, for that matter) is situated in Russia contradicts the official stance of the United States, Canada, the counties of the European Union, and many others. Suffice it to say, the international community never recognized Russia's claims to Crimea as valid and the so-called "referendum" as legally binding. The Unites States of America was also a signatory of the Budapest Memorandum on Security Assurances, which guarantees the territorial intergity of Ukraine. Let me add that the annexation of the Crimean peninsula in 2014 was only the first step of the Russian aggression against my country. The war in Donbas led by Russia is still ongoing and has costed dozens of thousands of Ukrainians their lives. As of 2016, the International Criminal Court officially recognized the war in Donbas as Russia's invasion of Ukraine. Russia and its allies has also put a lot of effort in spreading misinformation about the conflict, attempting to portray Ukraine as a far-right state and the Euromaidan protests as a coup. As an eyewitness to these events, I can assure you that it can not be further from truth, and, should you be interested, I can provide multiple sources that debunk this propaganda. Therefore, I humbly ask you to research this delicate matter. Once you have confirmed that pro-Russian sources are completely misinterpreting their far-from-innocuous role in the tragedy that shattered numerous families in my country, I hope that you will consider submitting corrections to your project and list all Crimean cities and respective timezones as Ukrainian. This would assure its compliance to the international standards, from both legal and moral viewpoint. I remain open to dialogue and would gladly answer any further questions you may happen to have. Looking forward to hearing from you, -- Best regards, Sergij Marchenko mailto:makars@gmail.com http://makar.homelinux.net Skype: makarsoft Viber/WhatsApp/Telegram/Signal: +380661877234

2 1

[PROPOSED 1/5] * tzfile.5: Typeset ‘-’ more carefully.
by Paul Eggert June 18, 2019

June 18, 2019

--- tzfile.5 | 30 +++++++++++++++--------------- 1 file changed, 15 insertions(+), 15 deletions(-) diff --git a/tzfile.5 b/tzfile.5 index d13029c..69f8860 100644 --- a/tzfile.5 +++ b/tzfile.5 @@ -119,13 +119,13 @@ that follow the structure(s) in the file. The .I tt_utoff -value is never equal to -2**31, to let 32-bit clients negate it without +value is never equal to \-2**31, to let 32-bit clients negate it without overflow. Also, in realistic applications .I tt_utoff -is in the range [-89999, 93599] (i.e., more than -25 hours and less +is in the range [\-89999, 93599] (i.e., more than \-25 hours and less than 26 hours); this allows easy support by implementations that -already support the POSIX-required range [-24:59:59, 25:59:59]. +already support the POSIX-required range [\-24:59:59, 25:59:59]. .IP * .I tzh_leapcnt pairs of four-byte values, written in network byte order; @@ -204,7 +204,7 @@ For version-3-format timezone files, the POSIX-TZ-style string may use two minor extensions to the POSIX TZ format, as described in .BR newtzset (3). First, the hours part of its transition times may be signed and range from -\*-167 through 167 instead of the POSIX-required unsigned values +\-167 through 167 instead of the POSIX-required unsigned values from 0 through 24. Second, DST is in effect all year if it starts January 1 at 00:00 and ends December 31 at 24:00 plus the difference @@ -239,7 +239,7 @@ in the version 1 data block to save space. Time zone designations should consist of at least three (3) and no more than six (6) ASCII characters from the set of alphanumerics, -.q "-", +.q "\*-", and .q "+". This is for compatibility with POSIX requirements for @@ -298,11 +298,11 @@ mishandled by version 2 readers. Some readers designed for version 2 do not support permanent daylight saving time, e.g., a TZ string .q "EST5EDT,0/0,J365/25" -denoting permanent Eastern Daylight Time (\*-04). +denoting permanent Eastern Daylight Time (\-04). As a partial workaround, a writer can substitute standard time for the next time zone east, e.g., .q "AST4" -for permanent Atlantic Standard Time (\*-04). +for permanent Atlantic Standard Time (\-04). .IP * Some readers ignore the footer, and instead predict future timestamps from the time type of the last transition. @@ -316,17 +316,17 @@ As a partial workaround, a writer can output a dummy (no-op) first transition at an early time. .IP * Some readers mishandle timestamps before the first -transition that has a timestamp not less than -2**31. +transition that has a timestamp not less than \-2**31. Readers that support only 32-bit timestamps are likely to be more prone to this problem, for example, when they process 64-bit transitions only some of which are representable in 32 bits. As a partial workaround, a writer can output a dummy -transition at timestamp \*-2**31. +transition at timestamp \-2**31. .IP * Some readers mishandle a transition if its timestamp has the minimum possible signed 64-bit value. -Timestamps less than \*-2**59 are not recommended. +Timestamps less than \-2**59 are not recommended. .IP * Some readers mishandle POSIX-style TZ strings that contain @@ -347,7 +347,7 @@ These characters are not recommended. Some readers may mishandle time zone abbreviations that contain fewer than 3 or more than 6 characters, or that contain ASCII characters other than alphanumerics, -.q "-", +.q "\*-", and .q "+". These abbreviations are not recommended. @@ -381,18 +381,18 @@ Readers that do not support negative timestamps are likely to be more prone to this problem. .IP * Some readers mishandle time zone abbreviations like -.q "-08" +.q "\*-08" that contain .q "+", -.q "-", +.q "\*-", or digits. .IP * Some readers mishandle UT offsets that are out of the -traditional range of \*-12 through +12 hours, and so do not +traditional range of \-12 through +12 hours, and so do not support locations like Kiritimati that are outside this range. .IP * -Some readers mishandle UT offsets in the range [\*-3599, \*-1] +Some readers mishandle UT offsets in the range [\-3599, \-1] seconds from UT, because they integer-divide the offset by 3600 to get 0 and then display the hour part as .q "+00". -- 2.21.0

1 4