So soon after the last one. Is it still too soon to suggest opaque ids again? On 10/9/18 14:52, Steven R. Loomis wrote:

Hello,

• Note that CLDR is already tracking this issue at https://unicode.org/cldr/trac/ticket/10185#comment:7 — the English usage was not (at present) compelling enough to make a change to the English side.

• Per the CLDR comparison charts, https://www.unicode.org/cldr/charts/latest/by_type/timezones.europe.html#6dd... you can note the spellings:

...

"Київ" for Ukranian, "Киев" for Russian. • As noted above, "Europe/Kiev" is just an identifier and not the correct thing to put in front of users.

• If you would like to explore CLDR translations for time zones, visit https://www.unicode.org/cldr/charts/latest/by_type/ and click on the various time zone links in the following line:

Timezones: Timezone Display Patterns | North America | South America | Africa | Europe | Russia | Western Asia | Central Asia | Eastern Asia | Southern Asia | Southeast Asia | Australasia | Antarctica | Oceania | Unknown Region | Overrides

Regards, Steven

On Tue, Oct 9, 2018 at 11:38 AM Paul Eggert <eggert@cs.ucla.edu> wrote:

...

Igor via tz wrote:

...

Ukrainian government is currently running a campaign called Kyiv Not Kiev If common English-language usage changes so that "Kyiv" is way more popular than "Kiev", we plan to change too. That hasn't happened yet.

...

I saw in your files that you understand that Kyiv is correct spelling and you reason that Kiev is more common, alas that argument is wrong. It's only more common because it's been mistakingly used for a long period of time. As a rule we don't judge who's right or who's wrong about spelling; we just take the most common English spelling. Anyway, the name "Europe/Kiev" is intended to be an internal identifier, not something visible to end users.

We've recently added text to try to explain this better, as follows:

Each timezone has a unique name. Inexperienced users are not expected to select these names unaided. Distributors should provide documentation and/or a simple selection interface that explains each name via a map or via descriptive text like "Ruthenia" instead of the timezone name "<code>Europe/Uzhgorod</code>". If geolocation information is available, a selection interface can locate the user on a timezone map or prioritize names that are geographically close. For an example selection interface, see the <code>tzselect</code> program in the <code><abbr>tz</abbr></code> code. The <a href="http://cldr.unicode.org/">Unicode Common Locale Data Repository</a> contains data that may be useful for other selection interfaces; it maps timezone names like <code>Europe/Uzhgorod</code> to CLDR names like <code>uauzh</code> which are in turn mapped to locale-dependent strings like "Uzhhorod", "Ungvár", "Ужгород", and "乌日哥罗德".

...

# From Paul Eggert (2018-10-03): # As is usual in tzdb, Ukrainian zones use the most common English spellings. # For example, tzdb uses Europe/Kiev, as "Kiev" is the most common spelling in # English for Ukraine's capital, even though it is certainly wrong as a # transliteration of the Ukrainian "Київ". This is similar to tzdb's use of # Europe/Prague, which is certainly wrong as a transliteration of the Czech # "Praha". ("Kiev" came from old Slavic via Russian to English, and "Prague" # came from old Slavic via French to English, so the two cases have something # in common.) Admittedly English-language spelling of Ukrainian names is # controversial, and some day "Kyiv" may become substantially more popular in # English; in the meantime, stick with the traditional English "Kiev" as that # means less disruption for our users. # # Anyway, none of the common English-language spellings (Kiev, Kyiv, Kieff, # Kijeff, Kijev, Kiyef, Kiyeff) do justice to the common pronunciation in # Ukrainian, namely [ˈkɪjiu̯] (IPA). This pronunciation has nothing like an # English "v" or "f", and instead trails off with what an English-speaker # would call a demure "oo" sound, and it would would be better anglicized as # "Kuiyu". Here's a sound file, if you would like to do as the Kuiyuvians do: # https://commons.wikimedia.org/wiki/File:Uk-Київ.ogg

On 10/9/18 15:53, Paul Eggert wrote:

On 10/9/18 12:15 PM, Michael Douglass wrote:

...

Is it still too soon to suggest opaque ids again?

Oh, probably. :-) I just couldn't resist it...

I've been filtering out duplicate messages notifying us that Brazil looks like it's going to start DST two weeks late this spring, as the messages are not adding any information to the topic. At some point it will be time to filter out duplicate "let's change 'Kiev' to 'Kyiv'" messages for the same reason, as the duplication will be causing more harm than good and this is irrespective of the merits of the arguments on either side.

This may not be based in anything more than my understanding from having seen these discussions play out time and time again over the years… but I do think there's something more worth stating, if only for the mailing list archives: It seems our general "consensus" sentiment toward these sorts of requests is that they're an extension of tz's goal to be descriptive, not prescriptive. This at least matches the similar discussion at CLDR: https://unicode.org/cldr/trac/ticket/10185#comment:2 Yes, our choice of English is arbitrary, but it is historical and there is a large (although certainly not insurmountable) amount of inertia behind it. Since it is regarded as a *lingua franca*, there are a wide body of sources with wide-ranging opinions on matters of geopolitics, which tz can leverage in helping decide how to record things. We, then, aim only to record rough consensus, much like other international standards organizations do, and attempt to leave the politics themselves to the politicians. Of course, even this can be regarded as a political stance, and in some sense, it is. And there are those who will still interpret that as *the maintainers* taking a side on any given geopolitical issue… but that can't really be helped. In cases of conflict, even the most meticulously-crafted "neutral" deferential position will naturally reflect the biases of some group of "others" — in our case, the biases of the news organizations and other entities to whom we defer in choosing to source our data. As long as we are upfront about that (and I think, for the most part, we are), then we are meeting the broader stated goal of being "useful even if not 100% accurate". And so, we do what we can to be diplomatic when the inevitable arises. (Which can, as Paul points out, include filtering duplication to ensure quality of discussion.) But if the necessity of that diplomacy grates on anyone, in either direction, then perhaps this isn't the list for them. ;) -- Tim Parenti On Tue, 9 Oct 2018 at 16:08, <Paul.Koning@dell.com> wrote:

...

On Oct 9, 2018, at 3:15 PM, Michael Douglass <mikeadouglass@gmail.com> wrote:

So soon after the last one.

Is it still too soon to suggest opaque ids again?

Yes.

paul

Numbers, when arbitrarily assigned, can be quite political, too. As are time zones themselves. Nearly everything can be made political, and that is the point. Nothing we can do will "free this project from politics" in any complete sense. To be clear, though, there is a difference between the general concept of English (which is spoken as a primarily language in several countries, and used secondarily by many organizations in nearly every country), and US English specifically. I, at least, have taken what measures I can to ensure we're dealing with the former, and not the latter, when it comes to place names. -- Tim Parenti On Tue, 9 Oct 2018 at 22:50, David Patte <dpatte@relativedata.com> wrote:

Numbers are not political. Using the name of a place in the languuage of a place is slightly more political. using an American derived name for a place that is not in the USA is definitely political. America/Montreal is totally insulting after two American invasions.

On 2018-10-09 22:27, Tim Parenti wrote:

This may not be based in anything more than my understanding from having seen these discussions play out time and time again over the years… but I do think there's something more worth stating, if only for the mailing list archives:

It seems our general "consensus" sentiment toward these sorts of requests is that they're an extension of tz's goal to be descriptive, not prescriptive. This at least matches the similar discussion at CLDR: https://unicode.org/cldr/trac/ticket/10185#comment:2

Yes, our choice of English is arbitrary, but it is historical and there is a large (although certainly not insurmountable) amount of inertia behind it. Since it is regarded as a *lingua franca*, there are a wide body of sources with wide-ranging opinions on matters of geopolitics, which tz can leverage in helping decide how to record things. We, then, aim only to record rough consensus, much like other international standards organizations do, and attempt to leave the politics themselves to the politicians.

Of course, even this can be regarded as a political stance, and in some sense, it is. And there are those who will still interpret that as *the maintainers* taking a side on any given geopolitical issue… but that can't really be helped. In cases of conflict, even the most meticulously-crafted "neutral" deferential position will naturally reflect the biases of some group of "others" — in our case, the biases of the news organizations and other entities to whom we defer in choosing to source our data. As long as we are upfront about that (and I think, for the most part, we are), then we are meeting the broader stated goal of being "useful even if not 100% accurate".

And so, we do what we can to be diplomatic when the inevitable arises. (Which can, as Paul points out, include filtering duplication to ensure quality of discussion.) But if the necessity of that diplomacy grates on anyone, in either direction, then perhaps this isn't the list for them. ;)

-- Tim Parenti

On Tue, 9 Oct 2018 at 16:08, <Paul.Koning@dell.com> wrote:

...

...

On Oct 9, 2018, at 3:15 PM, Michael Douglass <mikeadouglass@gmail.com> wrote:

So soon after the last one.

Is it still too soon to suggest opaque ids again?

Yes.

paul