Request for change to the tz database
Dear Arthur and Paul, I would like to draw your attention to one of the names of the UTC+2 time zone: Europe/Kiev . And suggest changing it to Europe/Kyiv. This name is derived from the name of Ukrainian capital “Київ”. Its official transliteration(1) is “Kyiv” and not “Kiev”. The transliteration “Kyiv” was approved by the Tenth United Nations Conference on Standardization of Geographical Names(2). This is a warranty of the campaign KyivNotKiev launched by Ministry of Foreign Affairs of Ukraine(3). This is a very important issue for Ukrainians in establishing our national identity in times of an armed conflict and hybrid war by propaganda and misinformation. “To appreciate the significance of the “Kyiv vs. Kiev” debate, one must first step back and view it in terms of the deep-rooted national identity crisis caused by centuries of Tsarist and Soviet russification.” (4) It would make a huge difference if you considered this suggestion! And please let me know, if there is something else I should do to substantiate this proposal. References: 1. According to the rules approved by Governmental decree from 27 January 2010 №55: https://www.kmu.gov.ua/npas/243262567 This particular example could be found there. 2. Resolution X/9. Romanization of Ukrainian geographical names could be found in the Report of the Conference: https://unstats.un.org/unsd/geoinfo/UNGEGN/docs/10th-uncsgn-docs/econf/E_CON... Document approved by the resolution: “Romanization System in Ukraine” https://unstats.un.org/unsd/geoinfo/UNGEGN/docs/10th-uncsgn-docs/econf/E_CON... 1. It may also be interesting for you to find out more about the movement on Wikipedia page: https://en.wikipedia.org/wiki/KyivNotKiev 2. An article on this matter in English could be found on Atlantic Council web-site: https://www.atlanticcouncil.org/blogs/ukrainealert/kyiv-not-kiev-why-spellin... Kind regards, Nadia Kobyliak [Изображение выглядит как знак Автоматически созданное описание] Nadia Kobyliak Senior project manager SOEs and Corporate Governance reform ________________________________ cell.: +38 097 642 35 29 12/2 Hrushevskoho str. me.gov.ua<http://www.me.gov.ua/> kobyliak.nadia@gmail.com<mailto:kobyliak.nadia@gmail.com> 01008 Kyiv Twitter<http://twitter.com/mineconomdev> NKobyliak@me.gov.ua<mailto:NKobyliak@me.gov.ua> Ukraine Facebook<http://facebook.com/mineconomdev>
Nadia Kobyliak said:
I would like to draw your attention to one of the names of the UTC+2 time zone: Europe/Kiev . And suggest changing it to Europe/Kyiv. [...] It would make a huge difference if you considered this suggestion!
It would make a huge difference if you read the archives of this mailing list to see how many times this topic has come up and what the responses were. -- Clive D.W. Feather | If you lie to the compiler, Email: clive@davros.org | it will get its revenge. Web: http://www.davros.org | - Henry Spencer Mobile: +44 7973 377646
On 2/8/21 8:27 AM, Clive D.W. Feather wrote:
It would make a huge difference if you read the archives of this mailing list to see how many times this topic has come up and what the responses were.
I sent a note privately to Nadia Kobyliak about this. Should I ask the tz mailing list moderators (who are not me) to filter out routine duplicate requests such as this one? At some point the duplicates start to drown out the more-useful email.
Huge +1 on this. I find the Kiev spam on this list /extremely/ annoying. It seems like the rule against delving into politics is completely counter-productive because so many e-mails and responses are spent explaining it to new people. Ideally once we realized something is a political hot-button that we're going to get a lot of e-mail about, we'd put it into some automated or semi-automated holding queue where the e-mail is held and the user gets an automated response pointing at the relevant entry in the FAQ. Best, Paul On 2/8/21 3:35 PM, Paul Eggert wrote:
On 2/8/21 8:27 AM, Clive D.W. Feather wrote:
It would make a huge difference if you read the archives of this mailing list to see how many times this topic has come up and what the responses were.
I sent a note privately to Nadia Kobyliak about this.
Should I ask the tz mailing list moderators (who are not me) to filter out routine duplicate requests such as this one? At some point the duplicates start to drown out the more-useful email.
One idea we’ve discussed in the past is directing those who wish to report issues to a web form that could work through things like structuring their submission, and perhaps present answers to common questions like the Kiev issue. It would also help address another challenge which is submitters aren’t necessarily aware that by emailing tz@iana.org<mailto:tz@iana.org> it is going to a public email list with hundreds of subscribers, and their contribution will be published online. If there is general support for the IANA team performing an initial triage for non-subscribers based on the content of their submission, we can work on setting something up. As Paul alludes to at present we are moderating non-subscriber submissions, but only to do a summary check that it is ‘on-topic’, i.e. related to time zone issues. kim From: tz <tz-bounces@iana.org> on behalf of Paul Ganssle <paul@ganssle.io> Date: Monday, February 8, 2021 at 12:46 PM To: "tz@iana.org" <tz@iana.org> Subject: Re: [tz] Request for change to the tz database Huge +1 on this. I find the Kiev spam on this list extremely annoying. It seems like the rule against delving into politics is completely counter-productive because so many e-mails and responses are spent explaining it to new people. Ideally once we realized something is a political hot-button that we're going to get a lot of e-mail about, we'd put it into some automated or semi-automated holding queue where the e-mail is held and the user gets an automated response pointing at the relevant entry in the FAQ. Best, Paul On 2/8/21 3:35 PM, Paul Eggert wrote: On 2/8/21 8:27 AM, Clive D.W. Feather wrote: It would make a huge difference if you read the archives of this mailing list to see how many times this topic has come up and what the responses were. I sent a note privately to Nadia Kobyliak about this. Should I ask the tz mailing list moderators (who are not me) to filter out routine duplicate requests such as this one? At some point the duplicates start to drown out the more-useful email.
Replies to several recent messages (from Paul, Paul, and Kim) inline: Paul Eggert <eggert@cs.ucla.edu> wrote on Mon, 8 Feb 2021 at 15:35:35 EST in <9b41fd25-14a2-c265-2668-caba0e853808@cs.ucla.edu>:
Should I ask the tz mailing list moderators (who are not me) to filter out routine duplicate requests such as this one? At some point the duplicates start to drown out the more-useful email.
If we had prepared a standard boilerplate answer that explained the issues and our position on them effectively, I think we could consider doing that. But we have not done so. Saying "go search the list archives" is not very user-friendly, and I don't think it's a reasonable request. Further, we have a pending proposal from Paul Eggert on how to address this -- a transition strategy, if you will. I'm not sure how much under discussion that really is, or if it is adopted by fiat or default, but nonetheless, the state of play today is rather different than it was four months ago. Paul Ganssle <paul@ganssle.io> wrote on Mon, 8 Feb 2021 at 15:45:36 EST in <d9bf3264-af1b-7802-ef2e-859560b1d416@ganssle.io>:
Huge +1 on this. I find the Kiev spam on this list /extremely/ annoying.
This language and this sentiment is actually offensive. The people advocating for Kiev-not-Kiev are not "spamming" the list. They are not sending email to the list that is unsolicited (if that even means anything for a mailing list). They are not sending email to the list that is commercial in nature. To be "spam," they need to meet both of thoses tests. I understand some people like to use the word "spam" to refer to things that are simply "annoying," but that's not what it means, and it's not a nice thing to do. We should not do it on this list. I will say, also, that a recent email about this reminded me of a rather significant hole in the common "[tz identifiers are not supposed to be user-visible, use tzselect() or something instead]" approach. And that is that there are quite a few situations where the tz identifier for a location is presented (e.g. "What is my system set to?" or databases and websites that display information about a locality and present its tz identifier). That only reinforces in my mind that, despite our desire to think otherwise, tz identifiers are indeed user-visible and pretending otherwise is just pretending. (I'm also struck that there is rarely a direct inquiry into what exact software the user is using that results in being presented with a tz identifier choice. I'd like to hope, if we were truly trying to be helpful, that we would ask that question.)
It seems like the rule against delving into politics is completely counter-productive because so many e-mails and responses are spent explaining it to new people. Ideally once we realized something is a political hot-button that we're going to get a lot of e-mail about, we'd put it into some automated or semi-automated holding queue where the e-mail is held and the user gets an automated response pointing at the relevant entry in the FAQ.
Well, I think it would be reasonable to produce such a FAQ and publish it, but I don't think we should pretermit discussion. And given, above, that the position that would be in that FAQ seem to be changing every few months, it's good cause not to automate the response to such inquiries. Kim Davies <kim.davies@iana.org> wrote on Mon, 8 Feb 2021 at 15:56:33 EST in <6FD15B30-1F90-4DAE-9307-A17A3EE4A3B0@iana.org>:
If there is general support for the IANA team performing an initial triage for non-subscribers based on the content of their submission, we can work on setting something up. As Paul alludes to at present we are moderating non-subscriber submissions, but only to do a summary check that it is ‘on-topic’, i.e. related to time zone issues.
Culturally speaking, this is not really how most Internet mailing lists work. I do not think that the magnitude of the "problem" supports a solution of that nature. Indeed, I think the emails to us are useful "check" on our administrative authority. If we were getting 1 inquiry from a new person about Kyiv each week, or each day, that would be telling us something. (Something which, I would argue, we should listen to). As it is, we're barely hitting one per month, on the average. -- jhawk@alum.mit.edu John Hawkinson
John Hawkinson said:
Huge +1 on this. I find the Kiev spam on this list /extremely/ annoying.
This language and this sentiment is actually offensive. The people advocating for Kiev-not-Kiev are not "spamming" the list. They are not sending email to the list that is unsolicited (if that even means anything for a mailing list). They are not sending email to the list that is commercial in nature. To be "spam," they need to meet both of thoses tests.
Sorry, but that's not so. A continual repeat of the same message *is* spam, whether commercial or not. In this case it's always presented as a political matter; politics can be spam even if they're not asking for money.
If we were getting 1 inquiry from a new person about Kyiv each week, or each day, that would be telling us something. (Something which, I would argue, we should listen to).
As it is, we're barely hitting one per month, on the average.
Really? It feels a lot more. -- Clive D.W. Feather | If you lie to the compiler, Email: clive@davros.org | it will get its revenge. Web: http://www.davros.org | - Henry Spencer Mobile: +44 7973 377646
"Clive D.W. Feather" <clive@davros.org> writes:
John Hawkinson said:
If we were getting 1 inquiry from a new person about Kyiv each week, or each day, that would be telling us something. (Something which, I would argue, we should listen to).
As it is, we're barely hitting one per month, on the average.
Really? It feels a lot more.
It feels like intermittent, very-low-scale brigading. There aren't any messages on the topic for some time, and then in the course of a week or so we get up to a half-dozen, all using similar wording as if they were all prompted by the same person or event. (Which makes sense; clearly it's an issue about which people have strong passions, and that sort of organizing is common in the political sphere.) -- Russ Allbery (eagle@eyrie.org) <https://www.eyrie.org/~eagle/>
On Mon, 8 Feb 2021 at 16:20, John Hawkinson <jhawk@alum.mit.edu> wrote:
Should I ask the tz mailing list moderators (who are not me) to filter out routine duplicate requests such as this one? At some point the duplicates start to drown out the more-useful email.
If we had prepared a standard boilerplate answer that explained the issues and our position on them effectively, I think we could consider doing that. But we have not done so.
In effect, we have such an answer now, and the details of that answer may evolve over time. So I agree we should actually start using that, as Paul has with the most recent threads, pointing people to his proposal at: https://mm.icann.org/pipermail/tz/2020-November/029542.html
Saying "go search the list archives" is not very user-friendly, and I don't think it's a reasonable request.
I am generally inclined to agree that "search the [entire/recent] list archives" would be ridiculous in most cases; however, as the frequency of these requests has increased, I would note that "check that it at least hasn't come up within the same month" is a comparatively low bar that often isn't being cleared. One compounding problem is that these requests go to a public list, and then others respond with text other than the boilerplate. On Mon, 8 Feb 2021 at 16:48, Clive D.W. Feather <clive@davros.org> wrote:
As it is, we're barely hitting one per month, on the average.
Really? It feels a lot more.
Until recently, it was about once a month. Lately, it's been more frequent. My inbox has Kiev/Kyiv threads starting on: 2020-08-15 2020-09-14 2020-11-26 2021-01-08 2021-01-18 (x2) 2021-02-05 2021-02-08 On Mon, 8 Feb 2021 at 16:55, Paul Eggert <eggert@cs.ucla.edu> wrote:
I was thinking more along the lines of something just for this topic, as in, if it's another Kyiv-vs-Kiev request just reply with the boilerplate. The idea is to tamp down the current problem, not come up with a general long-purpose solution.
Yes, and as the proposal moves forward, we could provide the IANA moderators with updated boilerplate as necessary. On Mon, 8 Feb 2021 at 16:56, Russ Allbery <eagle@eyrie.org> wrote:
It feels like intermittent, very-low-scale brigading. There aren't any messages on the topic for some time, and then in the course of a week or so we get up to a half-dozen, all using similar wording as if they were all prompted by the same person or event. (Which makes sense; clearly it's an issue about which people have strong passions, and that sort of organizing is common in the political sphere.)
#KyivNotKiev is a concerted online campaign sponsored by the Ukranian Ministry of Foreign Affairs, so it does make sense that a lot of the talking points in each message are similar, if not identical. https://en.wikipedia.org/wiki/KyivNotKiev But, yes, at some point, constant repetition doesn't add any value, and with most of these postings, I think we've long since passed that point, especially now that a proposed transition approach exists. If there is something truly new and novel to be discussed at some point, then we can have those discussions. But the same old back-and-forths are not productive for anyone. -- Tim Parenti
On Feb 8, 2021, at 1:40 PM, Clive D.W. Feather <clive@davros.org> wrote:
John Hawkinson said:
If we were getting 1 inquiry from a new person about Kyiv each week, or each day, that would be telling us something. (Something which, I would argue, we should listen to).
As it is, we're barely hitting one per month, on the average.
Really? It feels a lot more.
Looking through the list, the first such request I see is a side note in a 2013-03-25 email from Anton Shumskyi titled "Re: [tz] Ukraine time changes":
Ukraine will use DST from March 30, as of today nothing changes http://en.interfax.com.ua/news/general/141946.html
besides is there any way to correct some Ukrainian cities names (change from Russian transliteration to Ukrainian) 1. "Kiev -> Kyiv" 2. "Zaporozhye" -> "Zaporizhia" 3. "Uzhgorod" -> "Uzhhorod" 4. "Simferopol" is the correct name please see this as example http://en.wikipedia.org/wiki/List_of_cities_in_Ukraine
After that, there are requests on: 2014-04-14 2015-03-27 2016-04-01 2016-10-30 2016-12-01 2016-12-06 2017-12-07 2017-12-08 2018-03-05 2018-10-03 2018-10-09 2018-12-06 2019-05-08 2019-05-29 2019-06-21 2019-10-11 2020-02-18 2020-08-16 2020-09-14 2021-01-08 2021-01-18 2021-02-05 2021-02-08 So the traffic is bursty; we've recently had bursts in January and February, which makes it look more common than it is on average.
On Mon, Feb 8, 2021 at 1:19 PM John Hawkinson <jhawk@alum.mit.edu> wrote:
Saying "go search the list archives" is not very user-friendly, and I don't think it's a reasonable request.
I find searching the archives to be definitely *not* user-friendly. The main landing page (https://www.iana.org/time-zones) contains the "Archive" link to https://mm.icann.org/pipermail/tz/, but that page has no search capability. Most users will give up right here. Some users will remember that internet search engines can filter by URL. But only a fraction will remember the syntax: "site:mm.icann.org/pipermail/tz/ kiev kyiv". (I forget the syntax often, it's not something I do frequently.) The next problem is that some search engines do not seem to index the TZ archives very well. I use DuckDuckGo by default, and it returns only 2 results for "kiev kyiv", one from 2017 and another from 2016. Google is better, returning 134 results, but it is unclear how recent its search index is.
I don’t mean to belabor what is clearly a well trod and sore point, but why is the endonym for the most populous city in Ukraine any different than the endonym for the most populous city in West Bengal, or other cities whose endonym has changed its Latin transliteration or changed entirely? Perhaps I missed the previous discussion, but can’t we simply change the name of the zone in question to Europe/Kyiv and add Europe/Kiev as a synonym in tz/backward? This would reflect current modern Latin-script usage for the city in question, and would allow for backwards compatibility for clients using the older tz identifier, and would be similar to cases like Asia/Kolkata. On Mon, Feb 8, 2021 at 13:19 John Hawkinson <jhawk@alum.mit.edu> wrote:
Replies to several recent messages (from Paul, Paul, and Kim) inline:
Paul Eggert <eggert@cs.ucla.edu> wrote on Mon, 8 Feb 2021 at 15:35:35 EST in <9b41fd25-14a2-c265-2668-caba0e853808@cs.ucla.edu>:
Should I ask the tz mailing list moderators (who are not me) to filter out routine duplicate requests such as this one? At some point the duplicates start to drown out the more-useful email.
If we had prepared a standard boilerplate answer that explained the issues and our position on them effectively, I think we could consider doing that. But we have not done so. Saying "go search the list archives" is not very user-friendly, and I don't think it's a reasonable request.
Further, we have a pending proposal from Paul Eggert on how to address this -- a transition strategy, if you will. I'm not sure how much under discussion that really is, or if it is adopted by fiat or default, but nonetheless, the state of play today is rather different than it was four months ago.
Paul Ganssle <paul@ganssle.io> wrote on Mon, 8 Feb 2021 at 15:45:36 EST in <d9bf3264-af1b-7802-ef2e-859560b1d416@ganssle.io>:
Huge +1 on this. I find the Kiev spam on this list /extremely/ annoying.
This language and this sentiment is actually offensive. The people advocating for Kiev-not-Kiev are not "spamming" the list. They are not sending email to the list that is unsolicited (if that even means anything for a mailing list). They are not sending email to the list that is commercial in nature. To be "spam," they need to meet both of thoses tests.
I understand some people like to use the word "spam" to refer to things that are simply "annoying," but that's not what it means, and it's not a nice thing to do. We should not do it on this list.
I will say, also, that a recent email about this reminded me of a rather significant hole in the common "[tz identifiers are not supposed to be user-visible, use tzselect() or something instead]" approach. And that is that there are quite a few situations where the tz identifier for a location is presented (e.g. "What is my system set to?" or databases and websites that display information about a locality and present its tz identifier). That only reinforces in my mind that, despite our desire to think otherwise, tz identifiers are indeed user-visible and pretending otherwise is just pretending.
(I'm also struck that there is rarely a direct inquiry into what exact software the user is using that results in being presented with a tz identifier choice. I'd like to hope, if we were truly trying to be helpful, that we would ask that question.)
It seems like the rule against delving into politics is completely counter-productive because so many e-mails and responses are spent explaining it to new people. Ideally once we realized something is a political hot-button that we're going to get a lot of e-mail about, we'd put it into some automated or semi-automated holding queue where the e-mail is held and the user gets an automated response pointing at the relevant entry in the FAQ.
Well, I think it would be reasonable to produce such a FAQ and publish it, but I don't think we should pretermit discussion. And given, above, that the position that would be in that FAQ seem to be changing every few months, it's good cause not to automate the response to such inquiries.
Kim Davies <kim.davies@iana.org> wrote on Mon, 8 Feb 2021 at 15:56:33 EST in <6FD15B30-1F90-4DAE-9307-A17A3EE4A3B0@iana.org>:
If there is general support for the IANA team performing an initial triage for non-subscribers based on the content of their submission, we can work on setting something up. As Paul alludes to at present we are moderating non-subscriber submissions, but only to do a summary check that it is ‘on-topic’, i.e. related to time zone issues.
Culturally speaking, this is not really how most Internet mailing lists work. I do not think that the magnitude of the "problem" supports a solution of that nature.
Indeed, I think the emails to us are useful "check" on our administrative authority. If we were getting 1 inquiry from a new person about Kyiv each week, or each day, that would be telling us something. (Something which, I would argue, we should listen to).
As it is, we're barely hitting one per month, on the average.
-- jhawk@alum.mit.edu John Hawkinson
-- Scott Atwood
On Feb 8, 2021, at 2:09 PM, Scott Atwood <scott.roy.atwood@gmail.com> wrote:
I don’t mean to belabor what is clearly a well trod and sore point, but why is the endonym for the most populous city in Ukraine any different than the endonym for the most populous city in West Bengal, or other cities whose endonym has changed its Latin transliteration or changed entirely?
None; the issue is that the city names are *English-language* city names, and should reflect the most common English-language transliteration of non-English-language names. Over time, "Kyiv" is apparently becoming more common as a transliteration than "Kiev", so the change probably will be made at some point. (I, to my great delight, have no role in the decision to make that change. :-))
Perhaps I missed the previous discussion, but can’t we simply change the name of the zone in question to Europe/Kyiv and add Europe/Kiev as a synonym in tz/backward?
That's exactly the proposal from Paul Eggert mentioned in the message to which you're replying. That proposal is at https://mm.icann.org/pipermail/tz/2020-November/029542.html It involves making a "forward" link from Europe/Kyiv to Europe/Kiev, with the two being switched eventually, so that Europe/Kiev is a "backward" link to Europe/Kyiv.
Date: Mon, 8 Feb 2021 14:28:24 -0800 From: Guy Harris <gharris@sonic.net> Message-ID: <90554020-92B9-46CA-83DF-AC914E612DBE@sonic.net> | None; the issue is that the city names are *English-language* city names, Yes. | and should reflect the most common English-language transliteration | of non-English-language names. But not that. English names (whatever they are of) do not need transliterating into English, they already are. For some places English uses what are (effectively) transliterations of the local name, for others, the name isn't even similar Bangkok's name in Thai transliterates as Krungthep[MaHa.....] (it keeps going, it is a very long name, but is most commonly abbreviated to Krungthep) (the leading K is pronounced like a G in English). In tz we use Bangkok, as that's the English name. I don't much care what Kiev/Kyiv is called in English (Kiev is what it has always been to me, and will probably remain that way, but it isn't as if I use the name anywhere other than here). However, the content of recent messages makes it appear that someone has started a campaign ("Please help get the name changed, by sending e-mail to... and in it say ..."). Because of that I am (for now) opposed to making any change at all to this one (and I don't care what Google, or various newspapers, etc, have decided to do). If we start paying attention to this kind of thing we're simply inviting it to happen again. So say, "Sorry, no, your campaign has caused us to decide to retain the current name" and nothing else. kre
[ disclaimer: I just lurk here ] Robert Elz <kre@munnari.OZ.AU> writes:
I don't much care what Kiev/Kyiv is called in English (Kiev is what it has always been to me, and will probably remain that way, but it isn't as if I use the name anywhere other than here). However, the content of recent messages makes it appear that someone has started a campaign ("Please help get the name changed, by sending e-mail to... and in it say ..."). Because of that I am (for now) opposed to making any change at all to this one (and I don't care what Google, or various newspapers, etc, have decided to do). If we start paying attention to this kind of thing we're simply inviting it to happen again. So say, "Sorry, no, your campaign has caused us to decide to retain the current name" and nothing else.
I get where you're coming from, but I think that would be the opposite of helpful; it'd just draw more complaining. I think you are right that there's a campaign going on to get people to switch the spelling, and not just in tzdb. (Wikipedia, for instance, seems to have switched years ago.) So what? English spellings of foreign places change all the time, and tzdb has generally followed along without much complaint. Just looking through the existing links: L America/Adak America/Atka L America/Nuuk America/Godthab L Asia/Ashgabat Asia/Ashkhabad L Asia/Kolkata Asia/Calcutta L Asia/Dhaka Asia/Dacca L Asia/Kathmandu Asia/Katmandu L Asia/Macau Asia/Macao L Asia/Yangon Asia/Rangoon L Asia/Thimphu Asia/Thimbu L Asia/Ulaanbaatar Asia/Ulan_Bator L Atlantic/Faroe Atlantic/Faeroe L Pacific/Pohnpei Pacific/Ponape L Pacific/Chuuk Pacific/Truk How is Kiev/Kyiv different from any of those cases? So I think tzdb should just add Kyiv as a link and be done with it. I don't much care which end of the link is considered the primary name, and I doubt the complainers would notice the difference either. regards, tom lane
On 2021-02-09 08:07:29 (+0800), Robert Elz wrote:
Date: Mon, 8 Feb 2021 14:28:24 -0800 From: Guy Harris <gharris@sonic.net> Message-ID: <90554020-92B9-46CA-83DF-AC914E612DBE@sonic.net>
| None; the issue is that the city names are *English-language* city names,
Yes.
| and should reflect the most common English-language transliteration | of non-English-language names.
But not that.
English names (whatever they are of) do not need transliterating into English, they already are. For some places English uses what are (effectively) transliterations of the local name, for others, the name isn't even similar Bangkok's name in Thai transliterates as Krungthep[MaHa.....] (it keeps going, it is a very long name, but is most commonly abbreviated to Krungthep) (the leading K is pronounced like a G in English). In tz we use Bangkok, as that's the English name.
I think the full Thai name of Bangkok (transliterated) would break NAME_MAX on many systems. :)
I don't much care what Kiev/Kyiv is called in English (Kiev is what it has always been to me, and will probably remain that way, but it isn't as if I use the name anywhere other than here). However, the content of recent messages makes it appear that someone has started a campaign ("Please help get the name changed, by sending e-mail to... and in it say ..."). Because of that I am (for now) opposed to making any change at all to this one (and I don't care what Google, or various newspapers, etc, have decided to do). If we start paying attention to this kind of thing we're simply inviting it to happen again. So say, "Sorry, no, your campaign has caused us to decide to retain the current name" and nothing else.
It's pretty clear that there's a campaign on. My gut reaction to people ganging up and screaming loudly is also to be more stubborn. However, this windmill has been tilting for much longer than the campaign has been on. At this stage, tilting back really isn't constructive. Philip -- Philip Paeps Senior Reality Engineer Alternative Enterprises
"Philip Paeps" <philip@trouble.is> writes:
It's pretty clear that there's a campaign on. My gut reaction to people ganging up and screaming loudly is also to be more stubborn. However, this windmill has been tilting for much longer than the campaign has been on. At this stage, tilting back really isn't constructive.
My personal vote (which counts for basically nothing, to be clear) is that we should go ahead and rename the zone because it clearly matters a lot to other people and I don't think it matters that much to the project (in the sense that I don't think the change is difficult or adds much additional work). I understand the concern about not wanting to constantly change identifiers if this becomes a trend, but (a) we've already made it hard enough to be daunting, and (b) we're safely behind major news media style guides and I think that's enough of a guard rail on the slippery slope. I also have that gut reaction of digging in my heels when I feel like people are brigading, but I think here it's people who don't feel like they have any power other than numbers and writing (in general quite polite) email messages. It's not clear what else they can do to persuade us to change the name, and compared to most campaigns on the modern Internet they're being fairly restrained and polite about it. -- Russ Allbery (eagle@eyrie.org) <https://www.eyrie.org/~eagle/>
On 2021-02-08 17:07, Robert Elz wrote:
Date: Mon, 8 Feb 2021 14:28:24 -0800 From: Guy Harris <gharris@sonic.net> Message-ID: <90554020-92B9-46CA-83DF-AC914E612DBE@sonic.net>
| None; the issue is that the city names are *English-language* city names,
Yes.
| and should reflect the most common English-language transliteration | of non-English-language names.
But not that.
English names (whatever they are of) do not need transliterating into English, they already are. For some places English uses what are (effectively) transliterations of the local name, for others, the name isn't even similar Bangkok's name in Thai transliterates as Krungthep[MaHa.....] (it keeps going, it is a very long name, but is most commonly abbreviated to Krungthep) (the leading K is pronounced like a G in English). In tz we use Bangkok, as that's the English name.
I don't much care what Kiev/Kyiv is called in English (Kiev is what it has always been to me, and will probably remain that way, but it isn't as if I use the name anywhere other than here). However, the content of recent messages makes it appear that someone has started a campaign ("Please help get the name changed, by sending e-mail to... and in it say ..."). Because of that I am (for now) opposed to making any change at all to this one (and I don't care what Google, or various newspapers, etc, have decided to do). If we start paying attention to this kind of thing we're simply inviting it to happen again. So say, "Sorry, no, your campaign has caused us to decide to retain the current name" and nothing else.
Agreed! One of the most important lessons in developing and maintaining production software is learning to say "No!" sometimes "Hell, NO!" in response to some issues or requests that provide no benefit to the project or product, but may only introduce bugs in the project or product, or downstream. In the commercial world we can say, these parts make sense, and if you want us to do that for you, we estimate it will cost $X00k/$XM to conduct and provide an impact assessment, develop that, change all interfaces, retest, and redeploy the app, site, system, and everything. In the open source world, maintainer effort and time is the cost, as is the impact downstream on other projects, who have to conduct and provide an impact assessment to decide do we want to pass on these changes to our downstreams, or maintain patches to revert them to maintain stability to our downstreams, and do we have that capability if the project has constraints? Given tz downstreams are every major system and vendor in the world, and other projects like CLDR, who have their own release schedules, and possibly contributor or volunteer limits on the time and effort they can provide, stability of *ALL* external interfaces *MUST* be a major consideration. -- 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.]
On 2/8/21 1:19 PM, John Hawkinson wrote:
If we were getting 1 inquiry from a new person about Kyiv each week, or each day, that would be telling us something. (Something which, I would argue, we should listen to).
As it is, we're barely hitting one per month, on the average.
Recently we've been getting more than that. The email archives currently say 20 of this month's 26 messages have been about Kyiv vs Kiev. (This email will make it 21 out of 27. :-) And I recall plenty more messages in recent months. Even if we get only three inquiries per month, if their threads mushroom into three dozen emails per month then it's causing significant disruption. The compromise proposal I made in November (see URL below) received only one comment <https://mm.icann.org/pipermail/tz/2020-November/029568.html>, which suggested to not bother with a compromise and to just rename the entry then. Although I installed neither suggestion so tzdb still uses "Europe/Kiev", I still view the compromise or some variant as being on the table. For now, I propose that moderators respond to routine Kyiv-vs-Kiev requests with the following newly-edited boilerplate. ------ Thanks, we're aware of the renaming effort, and this has been a periodic source of discussion on the tz mailing list. A transition plan for Europe/Kiev → Europe/Kyiv was proposed here: https://mm.icann.org/pipermail/tz/2020-November/029542.html and you can review that email thread. There's no rush; tzdb tends to move slowly about these things, due to compatibility concerns. The choice of spelling should not be important to end users, as the tzdb spelling is not intended to be visible to them. End users should see their preferred spelling which would typically be Київ, but could also be Kyiv, Kænugarður, Κίεβο, 基輔, or whatever else is appropriate for the user's locale. The Unicode Common Locale Data Repository (CLDR) is a good source for these localized names; see <http://cldr.unicode.org/>. Admittedly it is all too common for software applications to expose strings like "Europe/Kiev" to users who prefer a different name; if this occurs in an application that you use, please send a bug report mentioning CLDR to the application's developers. Thanks.
Paul Eggert <eggert@cs.ucla.edu> wrote on Mon, 8 Feb 2021 at 17:24:39 EST in <5428025b-2f3c-3e09-7594-37d8e135fbd7@cs.ucla.edu>:
The compromise proposal I made in November (see URL below) received only one comment <https://mm.icann.org/pipermail/tz/2020-November/029568.html>, which suggested to not bother with a compromise and to just rename the entry then.
I did not reply to your compromise proposal because I thought it was clear from my prior input that I agreed with the idea that an interim compromise was pointless and summary renaming was appropriate. I suspect many others who expressed themselves before similarly did not offer their opinion, because it would feel like repetition. And, of course, we don't operate on raw counts of messages, except when we do. I dunno if we still reject kings, presidents, and voting though -- that's not us, and we do kind of have some folks in authority positions. -- jhawk@alum.mit.edu John Hawkinson
On 2021-02-09 06:31:22 (+0800), John Hawkinson wrote:
Paul Eggert <eggert@cs.ucla.edu> wrote on Mon, 8 Feb 2021 at 17:24:39 EST in <5428025b-2f3c-3e09-7594-37d8e135fbd7@cs.ucla.edu>:
The compromise proposal I made in November (see URL below) received only one comment <https://mm.icann.org/pipermail/tz/2020-November/029568.html> , which suggested to not bother with a compromise and to just rename the entry then.
I did not reply to your compromise proposal because I thought it was clear from my prior input that I agreed with the idea that an interim compromise was pointless and summary renaming was appropriate. I suspect many others who expressed themselves before similarly did not offer their opinion, because it would feel like repetition.
(It was I who posted the only comment on Paul's proposal in November expressing a preference for summary renaming.) Note that I am not opposed to the compromise proposal Paul suggested. Though my preference for summary renaming stands. It is clear that we will eventually have a Europe/Kyiv. We might as well get it over with. We have an established and reasonably exercised backward compatibility mechanism for people who need it. Trying out forward compatibility seems to provide few benefits. Philip -- Philip Paeps Senior Reality Engineer Alternative Enterprises
On 2021-02-08 16:06, Philip Paeps wrote:
On 2021-02-09 06:31:22 (+0800), John Hawkinson wrote:
Paul Eggert <eggert@cs.ucla.edu> wrote on Mon, 8 Feb 2021 at 17:24:39 EST in <5428025b-2f3c-3e09-7594-37d8e135fbd7@cs.ucla.edu>:
The compromise proposal I made in November (see URL below) received only one comment <https://mm.icann.org/pipermail/tz/2020-November/029568.html> , which suggested to not bother with a compromise and to just rename the entry then.
I did not reply to your compromise proposal because I thought it was clear from my prior input that I agreed with the idea that an interim compromise was pointless and summary renaming was appropriate. I suspect many others who expressed themselves before similarly did not offer their opinion, because it would feel like repetition.
(It was I who posted the only comment on Paul's proposal in November expressing a preference for summary renaming.)
Note that I am not opposed to the compromise proposal Paul suggested. Though my preference for summary renaming stands. It is clear that we will eventually have a Europe/Kyiv. We might as well get it over with. We have an established and reasonably exercised backward compatibility mechanism for people who need it. Trying out forward compatibility seems to provide few benefits.
I doubt any of these posters actually use software that displays Kiev: they have made no mention of products or projects, and have been told to spam this address! They could also be Russian provocateurs. How can we know they are Ukrainian, as it is useful if Russian controlled systems can maintain or masquerade as Ukrainian identities, used in media campaigns to their own ends? Similar reasoning applies to similar posts about other locales. No change should be required if we are using internal identifier names. We should decide that either all location identifiers be maintained as the current English identifiers as they are identifier names relevant only to technical communications, or all should be renamed to their local Latinizations e.g. Roma, Lisboa, as opinions of their their local users take precedence. Then table reconsideration for five (or ten) years to see if anything changes. "Rough concensus and running code" matters, unnecessary fiddling causes bugs! Mumbai vs Bombay is the only name change I would consider commonly recognized by most English speakers, but Kolkata, Kyiv, etc. are not, and neither are most country and city renamings in recent decades, nor are they widely used when they appear in the press, often requiring their previous names to provide relevancy. [I still see widely recognized names such as Burma and Rangoon used in the popular press to explain what's going on in what's now called Myanmar, as few recognize the latter; people have no interest or care about what happens in countries whose names they no longer recognize. Languages and names are about communication and comprehension: change names if you want to hinder communication and comprehension, and interest and caring as consequences.] -- 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.]
This is the most appropriate response I have heard. As English language influence wanes, the best option is always to localize names, otherwise everyone in 20 years will be forced to use identifiers in Mandarin. On 2021-02-08 19:36, Brian Inglis wrote:
We should decide that either all location identifiers be maintained as the current English identifiers as they are identifier names relevant only to technical communications, or all should be renamed to their local Latinizations e.g. Roma, Lisboa, as opinions of their their local users take precedence. Then table reconsideration for five (or ten) years to see if anything changes. "Rough concensus and running code" matters, unnecessary fiddling causes bugs!
In article <45ed9ac6-bb6b-5037-0fa6-ed8984aeb27d@relativedata.com>, dpatte@relativedata.com (David Patte) wrote:
*From:* David Patte <dpatte@relativedata.com> *To:* tz@iana.org *Date:* Mon, 8 Feb 2021 20:37:09 -0500
As English language influence wanes, the best option is always to localize names, otherwise everyone in 20 years will be forced to use identifiers in Mandarin.
As has been pointed out many times, localisation of names is best done - can only be _properly_ done, including use of the correct alphabet, accents etc - by the UI making use of the CLDR or some other layer that is completely separate from the TZDB. Allowing the TZDB internal identifiers to simply exist as - internal identifiers. Personally, I believe that there has been plenty of time for devourers of the TZDB to get their act together and either use localisation or make an honest declaration to their users that they simply aren't going to bother. With that in mind, it is so very tempting to start a campaign, nagging for TZDB to take serious steps towards making it blindingly obvious that these are just identifiers. And start by changing "Kiev" to just "K__v". Stephen Goudge
On 2021-02-09 08:36:31 (+0800), Brian Inglis wrote:
On 2021-02-08 16:06, Philip Paeps wrote:
On 2021-02-09 06:31:22 (+0800), John Hawkinson wrote:
Paul Eggert <eggert@cs.ucla.edu> wrote on Mon, 8 Feb 2021 at 17:24:39 EST in <5428025b-2f3c-3e09-7594-37d8e135fbd7@cs.ucla.edu>:
The compromise proposal I made in November (see URL below) received only one comment <https://mm.icann.org/pipermail/tz/2020-November/029568.html> , which suggested to not bother with a compromise and to just rename the entry then.
I did not reply to your compromise proposal because I thought it was clear from my prior input that I agreed with the idea that an interim compromise was pointless and summary renaming was appropriate. I suspect many others who expressed themselves before similarly did not offer their opinion, because it would feel like repetition.
(It was I who posted the only comment on Paul's proposal in November expressing a preference for summary renaming.)
Note that I am not opposed to the compromise proposal Paul suggested. Though my preference for summary renaming stands. It is clear that we will eventually have a Europe/Kyiv. We might as well get it over with. We have an established and reasonably exercised backward compatibility mechanism for people who need it. Trying out forward compatibility seems to provide few benefits.
I doubt any of these posters actually use software that displays Kiev: they have made no mention of products or projects, and have been told to spam this address! They could also be Russian provocateurs. How can we know they are Ukrainian, as it is useful if Russian controlled systems can maintain or masquerade as Ukrainian identities, used in media campaigns to their own ends?
This is clutching at straws. One of the most recent posts actually included a screenshot. As John Hawkinson pointed out elsewhere in this thread: we shouldn't merely dismiss these discussions simply because they happen so regularly.
Mumbai vs Bombay is the only name change I would consider commonly recognized by most English speakers, but Kolkata, Kyiv, etc. are not, and neither are most country and city renamings in recent decades, nor are they widely used when they appear in the press, often requiring their previous names to provide relevancy.
That may just be because Mumbai is much more likely to appear in the media most English speakers consume than Kolkata... Mumbai is the financial capital of India. It also has one of the largest international airports in the country. You're not very likely to encounter Kolkata in English-language press (or advertising) outside India unless there's big bad news.
[I still see widely recognized names such as Burma and Rangoon used in the popular press to explain what's going on in what's now called Myanmar, as few recognize the latter; people have no interest or care about what happens in countries whose names they no longer recognize. Languages and names are about communication and comprehension: change names if you want to hinder communication and comprehension, and interest and caring as consequences.]
While there may be some confusion about Burma/Myanmar and Rangoon/Yangon, the mental gap between Kiev and Kyiv is a lot narrower. Note that the most recent Godthab/Nuuk was a much more substantial burden on the Anglophone eye. The identifiers are largely an internal phenomenon. The only English speakers who really have to care are the maintainers of the tz database and the maintainers of software that consumes the tz database. One would hope that these folks can cope with the very occasional rename. I don't think anyone will accuse us of being cavalier about the stability of our identifiers. Philip -- Philip Paeps Senior Reality Engineer Alternative Enterprises
On Feb 8, 2021, at 5:40 PM, Philip Paeps <philip@trouble.is> wrote:
On 2021-02-09 08:36:31 (+0800), Brian Inglis wrote:
I doubt any of these posters actually use software that displays Kiev: they have made no mention of products or projects, and have been told to spam this address! They could also be Russian provocateurs. How can we know they are Ukrainian, as it is useful if Russian controlled systems can maintain or masquerade as Ukrainian identities, used in media campaigns to their own ends?
This is clutching at straws. One of the most recent posts actually included a screenshot.
It did not appear to be a screenshot of an application displaying a TZDB ID, however, and TZDB IDs are what we're discussing. As far as I know, nobody's doubting that it's Київ in Ukrainian or that Київ is Latinized as "Kyiv". As far as I know, the reason why "Europe/Kiev" was chosen is that, at the time it was chosen, the most common English-language Latinization of the name was "Kiev". Either that's no longer the case or it's becoming increasingly less and less the case, so that it won't be the case soon, in which case this is just like Bombay -> Mumbai or Calcutta -> Kolkata, and should be treated the same. (And, while I suspect most people, even in Ukraine, never see Europe/Kiev presented, 1) at least some of the people requesting the name change are, I suspect, people who deal with TZDB IDs, and thus *do* see Europe/Kiev presented, and 2) I doubt this is an Evil Russian Plot(TM) that's already ensnared the Associated Press and the Wall Street Journal, as well as the New York Times (see the note at the top of the article): https://www.nytimes.com/2019/11/13/us/politics/kiev-pronunciation.html and possibly other news sources and other organizations.)
[I still see widely recognized names such as Burma and Rangoon used in the popular press to explain what's going on in what's now called Myanmar, as few recognize the latter; people have no interest or care about what happens in countries whose names they no longer recognize. Languages and names are about communication and comprehension: change names if you want to hinder communication and comprehension, and interest and caring as consequences.]
While there may be some confusion about Burma/Myanmar and Rangoon/Yangon,
...and our official name, in the asia file, is Asia/Yangon. (In the comments before the entry for Asia/Yangon, it speaks of "Burma / Myanmar".) Asia/Rangoon is a link from the backward file.
On 2021-02-08 14:19, John Hawkinson wrote:
Replies to several recent messages (from Paul, Paul, and Kim) inline:
Paul Eggert wrote on Mon, 8 Feb 2021 at 15:35:35 EST:
Should I ask the tz mailing list moderators (who are not me) to filter out routine duplicate requests such as this one? At some point the duplicates start to drown out the more-useful email.
If we had prepared a standard boilerplate answer that explained the issues and our position on them effectively, I think we could consider doing that. But we have not done so. Saying "go search the list archives" is not very user-friendly, and I don't think it's a reasonable request.
Further, we have a pending proposal from Paul Eggert on how to address this -- a transition strategy, if you will. I'm not sure how much under discussion that really is, or if it is adopted by fiat or default, but nonetheless, the state of play today is rather different than it was four months ago.
These posts are akin to telling contributors to write in Ukrainian or ... I would suggest assigning them the action of translating the project and contributions into their preferred language and getting it adopted by IANA. I wish them luck in their endeavours, as it will ensure even less attention by English readers to Ukrainian affairs, and congratulate them on their support of their opponent's goals.
Paul Ganssle wrote on Mon, 8 Feb 2021 at 15:45:36 EST:
Huge +1 on this. I find the Kiev spam on this list /extremely/ annoying.
This language and this sentiment is actually offensive.
The people advocating for Kiev-not-Kiev are not "spamming" the list. They are not sending email to the list that is unsolicited (if that even means anything for a mailing list). They are not sending email to the list that is commercial in nature. To be "spam," they need to meet both of thoses tests. I understand some people like to use the word "spam" to refer to things that are simply "annoying," but that's not what it means, and it's not a nice thing to do. We should not do it on this list. We should try to maintain mutual respect and avoid cultural flash points by not expressing (too many) non-technical opinions, and try to ignore such comments and opinions as we ignore typos.
Using "spam" is modern hyperbolic jargon across communications media for what used to be called "line noise"; offense is merely another expression of an opinion in the eye of the beholder, the culture they inhabit, and their often vivid imaginations: c.f. Mrs. Grundy, Thomas Bowdler, Mary Whitehouse, Anthony Comstock, J. Edgar Hoover, Joe McCarthy, Potter Stewart ;^>
I will say, also, that a recent email about this reminded me of a rather significant hole in the common "[tz identifiers are not supposed to be user-visible, use tzselect() or something instead]" approach. And that is that there are quite a few situations where the tz identifier for a location is presented (e.g. "What is my system set to?" or databases and websites that display information about a locality and present its tz identifier). That only reinforces in my mind that, despite our desire to think otherwise, tz identifiers are indeed user-visible and pretending otherwise is just pretending.
It may be more prevalent in libre projects in English e.g. Mozilla Lightning Calendar, and other products with no or little background in alternate locale support, nor volunteer time to provide an alternative interface (possibly based on tzselect).
(I'm also struck that there is rarely a direct inquiry into what exact software the user is using that results in being presented with a tz identifier choice. I'd like to hope, if we were truly trying to be helpful, that we would ask that question.) That approach, the suggestion to contact their product support, as those internal identifier names should not be visible to users, suggesting they take responsibility to provide the product with translations or localizations in their preferred language, is probably the best approach to take.
It seems like the rule against delving into politics is completely counter-productive because so many e-mails and responses are spent explaining it to new people. Ideally once we realized something is a political hot-button that we're going to get a lot of e-mail about, we'd put it into some automated or semi-automated holding queue where the e-mail is held and the user gets an automated response pointing at the relevant entry in the FAQ.
AFAICT there is no FAQ - pointers? Suggestions? Perhaps someone with sufficient interest could break down the theory and how-to documents and present their contents in FAQ form to address the most common issues?
Well, I think it would be reasonable to produce such a FAQ and publish it, but I don't think we should pretermit discussion. And given, above, that the position that would be in that FAQ seem to be changing every few months, it's good cause not to automate the response to such inquiries.
Kim Davies wrote on Mon, 8 Feb 2021 at 15:56:33 EST:
If there is general support for the IANA team performing an initial triage for non-subscribers based on the content of their submission, we can work on setting something up. As Paul alludes to at present we are moderating non-subscriber submissions, but only to do a summary check that it is ‘on-topic’, i.e. related to time zone issues.
Culturally speaking, this is not really how most Internet mailing lists work. I do not think that the magnitude of the "problem" supports a solution of that nature.
Indeed, I think the emails to us are useful "check" on our administrative authority. If we were getting 1 inquiry from a new person about Kyiv each week, or each day, that would be telling us something. (Something which, I would argue, we should listen to). It's a political campaign, somewhat similar to that against Paul's dropping poorly sourced, country specific, pre-1970 info and zones where the record did not justify that, and merging a number of zones, because the lack would impact those (commercial?) products, uses, and users more than having inaccurate data from Shanks et al.
As it is, we're barely hitting one per month, on the average.
Other lists use milters with standard replies to common non-subscriber posts of a certain nature, often pointing to FAQs (see above suggestions). Perhaps the mods could trigger a standard reply suggesting their product support be contacted and informed of the issue (see above suggestions). This could have the positive benefit of making products aware of their interface limitations. -- 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.]
On 2021-02-09 07:23:51 (+0800), Brian Inglis wrote:
On 2021-02-08 14:19, John Hawkinson wrote:
As it is, we're barely hitting one per month, on the average.
Other lists use milters with standard replies to common non-subscriber posts of a certain nature, often pointing to FAQs (see above suggestions).
Perhaps the mods could trigger a standard reply suggesting their product support be contacted and informed of the issue (see above suggestions). This could have the positive benefit of making products aware of their interface limitations.
Not to pick on Brian but this is as good a place in this thread as any to point this out... This thread seems to have drifted towards trying to find a technical solution to a non-technical problem. The flood (trickle?) of posts to the list from people asking (demanding?) we rename Europe/Kiev to Europe/Kyiv is not the problem we should be trying to solve. I believe it's clear to most subscribers to the tz list that we'll eventually end up renaming Europe/Kiev to Europe/Kyiv, just as we renamed Asia/Calcutta to Asia/Kolkata and America/Godthab to America/Nuuk. The open questions are when this will happen and how - either using a new forward compatibility mechanism as proposed by Paul in November or using the existing backward compatibility mechanism. Philip -- Philip Paeps Senior Reality Engineer Alternative Enterprises
On Feb 8, 2021, at 3:23 PM, Brian Inglis <Brian.Inglis@systematicsw.ab.ca> wrote:
It may be more prevalent in libre projects in English e.g. Mozilla Lightning Calendar, and other products with no or little background in alternate locale support, nor volunteer time to provide an alternative interface (possibly based on tzselect).
Ubuntu's time zone selection UI, when I last looked at it, was pretty good (not as nice as macOS's, but what is?), but Ubuntu probably has more locale support and volunteer time.
On Mon, 8 Feb 2021 at 18:24, Brian Inglis <Brian.Inglis@systematicsw.ab.ca> wrote:
(I'm also struck that there is rarely a direct inquiry into what exact software the user is using that results in being presented with a tz identifier choice. I'd like to hope, if we were truly trying to be helpful, that we would ask that question.) That approach, the suggestion to contact their product support, as those internal identifier names should not be visible to users, suggesting they take responsibility to provide the product with translations or localizations in their preferred language, is probably the best approach to take.
We have used that approach for quite some time. One shortcoming, though, is that I get the sense that a lot of vendors react with a WONTFIX or "that's an upstream problem", trying to pass the buck back at us. And I get it. Developing a really *good* UI for timezone selection is hard, especially if you're doing it from scratch and it's not the core of your product. Indeed, we've seen a few threads saying, in effect, "we've reached out to our vendor, but they say they can't change the IDs because they get them straight from tz". Yes, there's a line or two in our theory file that says pretty emphatically NOT to do that, but perhaps some clearer "best practices" guidelines for downstream users of this project could stand to be fleshed out. Maybe tzselect should spawn a cousin that operates a bit closer to our favorite exemplars in macOS and Ubuntu. Regardless, fixing where that sense of (shared) responsibility should be placed is largely a social problem that won't easily or quickly go away, but we should continue to try to lead by example. Even so, as software development in general continues to become more prevalent, more and more people are being exposed to these identifiers in their natural environment anyway, which must also be considered.
Indeed, I think the emails to us are useful "check" on our administrative
authority. If we were getting 1 inquiry from a new person about Kyiv each week, or each day, that would be telling us something. (Something which, I would argue, we should listen to). It's a political campaign, somewhat similar to that against Paul's dropping poorly sourced, country specific, pre-1970 info and zones where the record did not justify that, and merging a number of zones, because the lack would impact those (commercial?) products, uses, and users more than having inaccurate data from Shanks et al.
In some ways, the raw number and frequency of similar requests matters: it is a signal of interest. In others, it does not: if everyone is repeating the same talking points, it doesn't move discussion forward and only means that we're hearing the "squeakiest" wheels, not necessarily what will best serve the userbase as a whole. To the extent that the raw counts do matter, employing moderation could still, in theory, result in a periodic summarization without subjecting the list to needless repetition, e.g., "we got N such requests this month, a few of them made the following points which seem novels." That would be just as useful a signal to us as N long, winding, (and heated!) email threads if they fail to offer much that's new. On the technical side, Paul made his proposal in November, and a major goal of that proposal was to *actually discuss its merits and flaws* prior to its potential implementation. It seems, from limited commentary then and a bit more commentary now, that the interim (forward-compatibility) approach is somewhat less favored. I'm inclined to agree that this need not be treated as a special case that introduces more complexity to the project. But it's important that that discussion actually happens before any change is implemented. I can't guess whether, upon making such a change, we wouldn't swiftly see a similar campaign to "change it back!" And then what? So, please… do speak up if you have anything new to add on the technical side. Whatever approach we take — in this case as in any other — needs to be supported by the data. Whether that needs to be in absolute terms or in terms of a clear trend is of course subject to interpretation, and so, though it seems to me that folks both on and off this list are indeed generally moving toward supporting this change, moderating and using a boilerplate response in the meantime can help provide our volunteers with the space and breathing room to conduct the necessary work to back it up with its due diligence. And then, hopefully, we can instead be discussing whether/how that data makes this clearer. -- Tim Parenti
I want to reiterate two points, that seem like they are getting lost, although, Tim, your message touched on them: 1) These emails from list outsiders have been quite effective in moving forward the on-list discussion about Kyiv. I don't think Paul's November proposal would have happened if we didn't have them, and to me it appears there is more and more concensus now about how to move forward, and again it is triggered by these outside emails. Shutting them down because they are effective would be troubling. 2) As I raised earlier today, the validity of a tz identifer is about more than just the user interface for timezone selection, which is essentially a "solved problem," even if not every software package has solved it. That UI doesn't do anything for the people who ask, "What zone is my computer set to?" or those who ask, such as through the Google Timezone API https://developers.google.com/maps/documentation/timezone/overview, "What is the TZ identifier for this location or for this long/lat pair?" (That question is the logical outgrowth of the first screenshot that Yaroslav Bilko posted in his second email to the list on Friday. I'm not sure where that screenshot came from. I hope we're not so inured to these emails about Kyiv-not-Kiev that we cannot stop to read each one and look at the new points that are raised). -- jhawk@alum.mit.edu John Hawkinson Tim Parenti <tim@timtimeonline.com> wrote on Mon, 8 Feb 2021 at 19:18:19 EST in <CAFpi07wT3hXdmbhmygHj+_Mw1cbUir4YWf=NWh7gG24CkP_Cvg@mail.gmail.com>:
On Mon, 8 Feb 2021 at 18:24, Brian Inglis <Brian.Inglis@systematicsw.ab.ca> wrote:
(I'm also struck that there is rarely a direct inquiry into what exact software the user is using that results in being presented with a tz identifier choice. I'd like to hope, if we were truly trying to be helpful, that we would ask that question.) That approach, the suggestion to contact their product support, as those internal identifier names should not be visible to users, suggesting they take responsibility to provide the product with translations or localizations in their preferred language, is probably the best approach to take.
We have used that approach for quite some time. One shortcoming, though, is that I get the sense that a lot of vendors react with a WONTFIX or "that's an upstream problem", trying to pass the buck back at us.
And I get it. Developing a really *good* UI for timezone selection is hard, especially if you're doing it from scratch and it's not the core of your product. Indeed, we've seen a few threads saying, in effect, "we've reached out to our vendor, but they say they can't change the IDs because they get them straight from tz". Yes, there's a line or two in our theory file that says pretty emphatically NOT to do that, but perhaps some clearer "best practices" guidelines for downstream users of this project could stand to be fleshed out. Maybe tzselect should spawn a cousin that operates a bit closer to our favorite exemplars in macOS and Ubuntu. Regardless, fixing where that sense of (shared) responsibility should be placed is largely a social problem that won't easily or quickly go away, but we should continue to try to lead by example.
Even so, as software development in general continues to become more prevalent, more and more people are being exposed to these identifiers in their natural environment anyway, which must also be considered.
Indeed, I think the emails to us are useful "check" on our administrative
authority. If we were getting 1 inquiry from a new person about Kyiv each week, or each day, that would be telling us something. (Something which, I would argue, we should listen to). It's a political campaign, somewhat similar to that against Paul's dropping poorly sourced, country specific, pre-1970 info and zones where the record did not justify that, and merging a number of zones, because the lack would impact those (commercial?) products, uses, and users more than having inaccurate data from Shanks et al.
In some ways, the raw number and frequency of similar requests matters: it is a signal of interest. In others, it does not: if everyone is repeating the same talking points, it doesn't move discussion forward and only means that we're hearing the "squeakiest" wheels, not necessarily what will best serve the userbase as a whole. To the extent that the raw counts do matter, employing moderation could still, in theory, result in a periodic summarization without subjecting the list to needless repetition, e.g., "we got N such requests this month, a few of them made the following points which seem novels." That would be just as useful a signal to us as N long, winding, (and heated!) email threads if they fail to offer much that's new.
On the technical side, Paul made his proposal in November, and a major goal of that proposal was to *actually discuss its merits and flaws* prior to its potential implementation. It seems, from limited commentary then and a bit more commentary now, that the interim (forward-compatibility) approach is somewhat less favored. I'm inclined to agree that this need not be treated as a special case that introduces more complexity to the project. But it's important that that discussion actually happens before any change is implemented. I can't guess whether, upon making such a change, we wouldn't swiftly see a similar campaign to "change it back!" And then what? So, please… do speak up if you have anything new to add on the technical side.
Whatever approach we take — in this case as in any other — needs to be supported by the data. Whether that needs to be in absolute terms or in terms of a clear trend is of course subject to interpretation, and so, though it seems to me that folks both on and off this list are indeed generally moving toward supporting this change, moderating and using a boilerplate response in the meantime can help provide our volunteers with the space and breathing room to conduct the necessary work to back it up with its due diligence. And then, hopefully, we can instead be discussing whether/how that data makes this clearer.
-- Tim Parenti
On Feb 8, 2021, at 4:39 PM, John Hawkinson <jhawk@alum.mit.edu> wrote:
2) As I raised earlier today, the validity of a tz identifer is about more than just the user interface for timezone selection, which is essentially a "solved problem," even if not every software package has solved it. That UI doesn't do anything for the people who ask, "What zone is my computer set to?"
What sort of answer are they expecting? "Pacific time zone"/"Pacific time"? "US Pacific time zone"/"US Pacific time"? "The zone for {one of San Francisco, San Jose, Los Angeles, Menlo Park, ... (depending on what level of town/city is offered by the TZDB region selecting UI}"? Or "America/Los_Angeles"? The answer may depend on which such person you ask. Most people probably aren't familiar with the fine details of changes in DST rules - or even changes in *time zone* in the sense of "standard time offset from UTC" - in the history of a particular TZDB region, so a TZDB ID may be irrelevant to them, and it would probably be meaningless as well. Those who *do* understand TZDB regions (as opposed to "time zones") and want to know the TZDB region ID for the system should, if they're not already aware that the region IDs: don't necessarily correspond to the city nearest you, don't necessarily correspond to the *large* city nearest you, and don't necessarily correspond to the "most important" (by some criterion) city in the region; use "America" to refer to the Americas, not to the United States of America; don't necessarily arrange that the city used for the region you're in is closer to you than the city used for some *other* region; may not use the preferred English-language transliteration of the city's name; should be made aware of that. I.e., there are non-technical users, who should never have to see a TZDB ID unless they're reporting it to a support person, and technical users, who *do* need to know TZDB IDs, and the latter should understand the above characteristics about TZDB IDs.
or those who ask, such as through the Google Timezone API https://developers.google.com/maps/documentation/timezone/overview, "What is the TZ identifier for this location or for this long/lat pair?"
Only technical users should do that directly. Non-technical users users should be running software that does that for them and Does The Right Thing without showing them a TZDB ID.
On 2021-02-08 17:39, John Hawkinson wrote:
(That question is the logical outgrowth of the first screenshot that Yaroslav Bilko posted in his second email to the list on Friday. I'm not sure where that screenshot came from. I hope we're not so inured to these emails about Kyiv-not-Kiev that we cannot stop to read each one and look at the new points that are raised).
It's all part of the Ukrainian government's attempts to correct how English language sources spell Ukrainian names online: https://mfa.gov.ua/en/correctua although other languages appear free to continue using their own conventions. The relevant screenshot appears to be from some random web site(s) which scraped a bunch of country info including the tzids, possibly from some edition of something like the CIA World Factbook or similar public wiki source. Wikipedia still posts the tzids in: https://en.wikipedia.org/wiki/List_of_tz_database_time_zones Wikipedia's own recent sources still show significant English language authorities current online references retain Kiev, along with other spellings used in technical forums, and historical alternatives, mentioning Kyiv as a neologism conceived in 2018, while Kiev has been used since 1804. Sites claims that they can not change the info as it is derived from the tzid is probably based on their never bothering to update anything on the site until their ad hits go down enough to make an update the more profitable approach. Unfortunately we have all probably worked at places where we have seen tickets containing or heard support staff on calls making these excuses to clients. As it appears to be an English language site, they probably don't get many hits from Ukraine, except trolls searching for Kiev, so don't care about Ukrainian opinions. FYI CBC changed in 1999 as that was the CP agency usage, changed back to Kiev in 2004, changed again in 2011: https://www.cbc.ca/news2/indepth/words/kiev-or-kyiv.html [there are a number of articles under the URL basename and the index in: https://www.cbc.ca/news2/indepth/words/quick/queries_index.html covering contentious usages]. -- 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.]
On 2/8/21 12:56 PM, Kim Davies wrote:
One idea we’ve discussed in the past is directing those who wish to report issues to a web form that could work through things like structuring their submission, and perhaps present answers to common questions like the Kiev issue. It would also help address another challenge which is submitters aren’t necessarily aware that by emailingtz@iana.org<mailto:tz@iana.org> it is going to a public email list with hundreds of subscribers, and their contribution will be published online.
Although a web form would help, I expect it would do so only if filtered all non-subscribers as there are too many places that say the equivalent of "report bugs to tz@iana.org". And such a filter would be so off-putting for new contributors that it would plausibly cause more problems than it'd cure.
If there is general support for the IANA team performing an initial triage for non-subscribers based on the content of their submission, we can work on setting something up. As Paul alludes to at present we are moderating non-subscriber submissions, but only to do a summary check that it is ‘on-topic’, i.e. related to time zone issues.
I was thinking more along the lines of something just for this topic, as in, if it's another Kyiv-vs-Kiev request just reply with the boilerplate. The idea is to tamp down the current problem, not come up with a general long-purpose solution.
participants (17)
-
Brian Inglis -
Brian Park -
Clive D.W. Feather -
David Patte -
Guy Harris -
John Hawkinson -
Kim Davies -
Nadia Kobyliak -
Paul Eggert -
Paul Ganssle -
Philip Paeps -
Robert Elz -
Russ Allbery -
Scott Atwood -
Tim Parenti -
timezones＠clodane.uk -
Tom Lane