Rename Ukrainian cities to their official transliterated names
Hello. This is my first attempt on patching tz database. Hope I did everything right. Included patch renames Kiev to Kyiv, Uzhgorod to Uzhhorod and Zaporozhye to Zaporizhzhia according to official transliteration rules that came in effect 2014. According to Google search most sites are already using Uzhhorod and Zaporizhzhia to name cities, while with Kyiv it's a little bit complicated, as it's the capital so it's name was appearing on a huge list of sites throughout years... I'm just trying to bring a little bit of lawful sanity… Thanks in advance. -- Sphinx of black quartz judge my vow.
Please review the mailing list archives. This exact topic has been discussed (and rejected) many times in the past, several times per year. paul
On Oct 2, 2018, at 4:35 PM, Volodymyr Kostyrko <arcade@b1t.name> wrote:
[EXTERNAL EMAIL] Please report any suspicious attachments, links, or requests for sensitive information.
Hello.
This is my first attempt on patching tz database. Hope I did everything right.
Included patch renames Kiev to Kyiv, Uzhgorod to Uzhhorod and Zaporozhye to Zaporizhzhia according to official transliteration rules that came in effect 2014. According to Google search most sites are already using Uzhhorod and Zaporizhzhia to name cities, while with Kyiv it's a little bit complicated, as it's the capital so it's name was appearing on a huge list of sites throughout years...
I'm just trying to bring a little bit of lawful sanity…
Thanks in advance.
-- Sphinx of black quartz judge my vow. <kyivnotkiev.patch>
In particular, the spellings in current use by this project generally remain *much* more common in English-language media. This project attempts to reflect mainstream English-language spellings for place names (see theory.html), and explicitly does not attempt to reflect transliterations. See also this recent media review: https://mm.icann.org/pipermail/tz/2017-December/025770.html -- Tim Parenti On Wed, 3 Oct 2018 at 12:43, <Paul.Koning@dell.com> wrote:
Please review the mailing list archives. This exact topic has been discussed (and rejected) many times in the past, several times per year.
paul
On Oct 2, 2018, at 4:35 PM, Volodymyr Kostyrko <arcade@b1t.name> wrote:
[EXTERNAL EMAIL] Please report any suspicious attachments, links, or requests for sensitive information.
Hello.
This is my first attempt on patching tz database. Hope I did everything right.
Included patch renames Kiev to Kyiv, Uzhgorod to Uzhhorod and Zaporozhye to Zaporizhzhia according to official transliteration rules that came in effect 2014. According to Google search most sites are already using Uzhhorod and Zaporizhzhia to name cities, while with Kyiv it's a little bit complicated, as it's the capital so it's name was appearing on a huge list of sites throughout years...
I'm just trying to bring a little bit of lawful sanity…
Thanks in advance.
-- Sphinx of black quartz judge my vow. <kyivnotkiev.patch>
On Oct 3, 2018, at 10:04 AM, Tim Parenti <tim@timtimeonline.com> wrote:
In particular, the spellings in current use by this project generally remain much more common in English-language media. This project attempts to reflect mainstream English-language spellings for place names (see theory.html), and explicitly does not attempt to reflect transliterations.
And, again, for the 5 trillionth time: If a user interface shows the tzdb region names to most end users and requires most end users to set the tzdb region by selecting from a list of tzdb region names - and this includes names generated from tzdb region names, e.g. "helpfully" using "Los Angeles" in the "America" region rather than "America/Los_Angeles" to select the US Pacific time zone - it is not a good user interface. Those names are identifiers for software use, just as LANG environment variable settings such as en_US.UTF-8 are identifiers for software use, *not* names that most end users should have to deal with, so making the names "look appropriate" is not the highest priority.
03.10.18 20:46, Guy Harris wrote:
On Oct 3, 2018, at 10:04 AM, Tim Parenti <tim@timtimeonline.com> wrote:
In particular, the spellings in current use by this project generally remain much more common in English-language media. This project attempts to reflect mainstream English-language spellings for place names (see theory.html), and explicitly does not attempt to reflect transliterations.
And, again, for the 5 trillionth time:
If a user interface shows the tzdb region names to most end users and requires most end users to set the tzdb region by selecting from a list of tzdb region names - and this includes names generated from tzdb region names, e.g. "helpfully" using "Los Angeles" in the "America" region rather than "America/Los_Angeles" to select the US Pacific time zone - it is not a good user interface.
Those names are identifiers for software use, just as LANG environment variable settings such as en_US.UTF-8 are identifiers for software use, *not* names that most end users should have to deal with, so making the names "look appropriate" is not the highest priority.
I must admit that you are right. But the point is that this is not the final position everyone can agree with. Taking PHP community as a an example they are using raw zone names in their configuration files. If any thirdparty vendor would try to translate this zones in his application he will face a choice - to be correct about zone naming according to each language or to forfeit correctness in favor of clear and unambiguous configuration. And he should choose the latter. I can't blame him neither. Renaming things others depend upon is also a very sloppy path that shouldn't being followed so easily. Though this raises a problem similar to "master-and-slave" concept. Most people are feeling fine with the names as they are just a hollow words that mean nothing to them, though for a very limited number of people who faced slavery or humiliation this will be just a trigger and they will not stop fighting to make everyone else stop treating this words as "normal" and not "shameful". Most of you feel nothing about Kiev/Kyiv difference, but for a lot of Ukrainians the former is a sign of a communist slavery, the mark of alien possession over they father's land. Leaving things as they are will not solve the problem for them, and they wouldn't stop trying to change it. That's politics. Even if you try to stay unbiased and techy you have to choose something, and this choice will make your side. Probably this can be easily solved by scrapping full town names and switching to some indices like UAK/UAZ/UAU but that's totally out of the scope of my knowledge of tz database rules and principles. And also in this case I'm a biased person. Totally not for me to decide. Thank you. -- Sphinx of black quartz judge my vow.
Very good summary of the issue. Thank you. Yes, I would agree that for those that state they have issues with these names, they appear incorrect or humiliating - whether that was the intent or not. On 2018-10-03 17:13, Volodymyr Kostyrko wrote:
03.10.18 20:46, Guy Harris wrote:
On Oct 3, 2018, at 10:04 AM, Tim Parenti <tim@timtimeonline.com> wrote:
In particular, the spellings in current use by this project generally remain much more common in English-language media. This project attempts to reflect mainstream English-language spellings for place names (see theory.html), and explicitly does not attempt to reflect transliterations.
And, again, for the 5 trillionth time:
If a user interface shows the tzdb region names to most end users and requires most end users to set the tzdb region by selecting from a list of tzdb region names - and this includes names generated from tzdb region names, e.g. "helpfully" using "Los Angeles" in the "America" region rather than "America/Los_Angeles" to select the US Pacific time zone - it is not a good user interface.
Those names are identifiers for software use, just as LANG environment variable settings such as en_US.UTF-8 are identifiers for software use, *not* names that most end users should have to deal with, so making the names "look appropriate" is not the highest priority.
I must admit that you are right. But the point is that this is not the final position everyone can agree with.
Taking PHP community as a an example they are using raw zone names in their configuration files. If any thirdparty vendor would try to translate this zones in his application he will face a choice - to be correct about zone naming according to each language or to forfeit correctness in favor of clear and unambiguous configuration. And he should choose the latter. I can't blame him neither.
Renaming things others depend upon is also a very sloppy path that shouldn't being followed so easily. Though this raises a problem similar to "master-and-slave" concept. Most people are feeling fine with the names as they are just a hollow words that mean nothing to them, though for a very limited number of people who faced slavery or humiliation this will be just a trigger and they will not stop fighting to make everyone else stop treating this words as "normal" and not "shameful". Most of you feel nothing about Kiev/Kyiv difference, but for a lot of Ukrainians the former is a sign of a communist slavery, the mark of alien possession over they father's land. Leaving things as they are will not solve the problem for them, and they wouldn't stop trying to change it. That's politics. Even if you try to stay unbiased and techy you have to choose something, and this choice will make your side.
Probably this can be easily solved by scrapping full town names and switching to some indices like UAK/UAZ/UAU but that's totally out of the scope of my knowledge of tz database rules and principles. And also in this case I'm a biased person. Totally not for me to decide.
Thank you.
On 2018-10-04 08:45:03 (+0200), Paw Boel Nielsen via tz wrote:
it is not a good user interface. I propose we change all tz identifiers to randomly generated characters to ensure no UI designer considers showing them to end users.
This has been proposed several times. The main downside to that idea is that it would make the tzdb a lot more difficult to maintain. Philip -- Philip Paeps Senior Reality Engineer Ministry of Information
How about including a warning in the README file? Currently info on zone name are written in theory file however I don't think many programmers look into that when using tzdb 2018-10-4 14:58, Philip Paeps <philip@trouble.is> wrote:
On 2018-10-04 08:45:03 (+0200), Paw Boel Nielsen via tz wrote:
it is not a good user interface. I propose we change all tz identifiers to randomly generated characters to ensure no UI designer considers showing them to end users.
This has been proposed several times.
The main downside to that idea is that it would make the tzdb a lot more difficult to maintain.
Philip
-- Philip Paeps Senior Reality Engineer Ministry of Information
On Oct 3, 2018, at 11:45 PM, Paw Boel Nielsen via tz <tz@iana.org> wrote: .
I propose we change all tz identifiers to randomly generated characters to ensure no UI designer considers showing them to end users.
I've already made similar suggestions; that would get rid of the "why isn't it Asia/Beijing"? complaints, and would also mean I wouldn't get shown "America/Los_Angeles" as the appropriate choice even though I'm about 500 km from there.
On 04/10/2018 09:54, Guy Harris wrote:
I propose we change all tz identifiers to randomly generated characters to ensure no UI designer considers showing them to end users. I've already made similar suggestions; that would get rid of the "why isn't it Asia/Beijing"? complaints, and would also mean I wouldn't get shown "America/Los_Angeles" as the appropriate choice even though I'm about 500 km from there.
Given that so many end user systems are reliant simply on the tz identifiers that change would have a quite drastic effect. Perhaps moving forward the RFC for geolocate could be used as a base for a multilingual source of identifiers? -- Lester Caine - G8HFL ----------------------------- Contact - https://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - https://lsces.co.uk EnquirySolve - https://enquirysolve.com/ Model Engineers Digital Workshop - https://medw.co.uk Rainbow Digital Media - https://rainbowdigitalmedia.co.uk
On Oct 4, 2018, at 02:45, Paw Boel Nielsen via tz <tz@iana.org> wrote:
I propose we change all tz identifiers to randomly generated characters to ensure no UI designer considers showing them to end users.
All that would do is kick the problem up a level. At some point, there has to be some sort of *map* that defines which tz entry relates to what specific geographical region. ‘Randomized’ identifiers merely mean that that map would have to be maintained separately, but would still have all of the socio-political baggage about proper spelling, transliteration, etc, etc. I think the current identifier arrangement is about the cleanest approach possible for what is an inherently messy task. TZ adopters do need to understand that those identifiers are essentially arbitrary keys into a database. Cheers! |----------------------------------------------------------------------| | Frederick F. Gleason, Jr. | Chief Developer | | | Paravel Systems | |----------------------------------------------------------------------| | Like the ski resort of girls looking for husbands and husbands | | looking for girls, the situation is not as symmetrical as it might | | seem. | | -- Alan McKay | |----------------------------------------------------------------------|
On 10/4/18 09:05, Fred Gleason wrote:
On Oct 4, 2018, at 02:45, Paw Boel Nielsen via tz <tz@iana.org <mailto:tz@iana.org>> wrote:
I propose we change all tz identifiers to randomly generated characters to ensure no UI designer considers showing them to end users.
All that would do is kick the problem up a level. At some point, there has to be some sort of *map* that defines which tz entry relates to what specific geographical region. ‘Randomized’ identifiers merely mean that that map would have to be maintained separately, but would still have all of the socio-political baggage about proper spelling, transliteration, etc, etc.
Kicking it up a level is exactly what's needed.
I think the current identifier arrangement is about the cleanest approach possible for what is an inherently messy task. TZ adopters do need to understand that those identifiers are essentially arbitrary keys into a database. There are many approaches to this but separating the tz data from names is both simple and backward compatible with end consumers though it requires a little work to change the data and the tools which use that data.
1. Add a UID to the data 2. Remove the name 3. Create a mapping file of name<->uid 4. Change the tools to use that mapping file to create exactly the same output. Opaque ids are what some consumers have been asking for for some time because of the political implications of the names. The disadvantages to this approach are a little work. The advantages are that we can hand over maintenance of names to some other body (cldr?). We also get a uid which we know refers to a specific timezone We can then update rfc5545 to use the UID property in VTIMEZONE and add text to point out that the tzid is for reference only. Without this people will continue to start with the data they see and assume the id is for presentation to users. Eventually they might understand what's happening but there's always new people to confuse.
Cheers!
|----------------------------------------------------------------------| | Frederick F. Gleason, Jr. | Chief Developer | | | Paravel Systems | |----------------------------------------------------------------------| | Like the ski resort of girls looking for husbands and husbands | | looking for girls, the situation is not as symmetrical as it might | | seem. | | -- Alan McKay | |----------------------------------------------------------------------|
On 4 Oct 2018, at 15:33, Michael Douglass <mikeadouglass@gmail.com> wrote:
On 10/4/18 09:05, Fred Gleason wrote:
On Oct 4, 2018, at 02:45, Paw Boel Nielsen via tz <tz@iana.org <mailto:tz@iana.org>> wrote:
I propose we change all tz identifiers to randomly generated characters to ensure no UI designer considers showing them to end users.
All that would do is kick the problem up a level. At some point, there has to be some sort of *map* that defines which tz entry relates to what specific geographical region. ‘Randomized’ identifiers merely mean that that map would have to be maintained separately, but would still have all of the socio-political baggage about proper spelling, transliteration, etc, etc.
Kicking it up a level is exactly what's needed.
I think the current identifier arrangement is about the cleanest approach possible for what is an inherently messy task. TZ adopters do need to understand that those identifiers are essentially arbitrary keys into a database. There are many approaches to this but separating the tz data from names is both simple and backward compatible with end consumers though it requires a little work to change the data and the tools which use that data.
1. Add a UID to the data 2. Remove the name 3. Create a mapping file of name<->uid 4. Change the tools to use that mapping file to create exactly the same output.
Opaque ids are what some consumers have been asking for for some time because of the political implications of the names.
The disadvantages to this approach are a little work. The advantages are that we can hand over maintenance of names to some other body (cldr?). We also get a uid which we know refers to a specific timezone
We can then update rfc5545 to use the UID property in VTIMEZONE and add text to point out that the tzid is for reference only.
Without this people will continue to start with the data they see and assume the id is for presentation to users. Eventually they might understand what's happening but there's always new people to confuse.
I don't think it's that simple. The long-term stable Linux distros (eg RHEL, OL, CentOS, Ubuntu LTS) and possibly others (macOS?) are going to be with us for quite a few years yet and they will have to stick with the <region>/<locale> identifiers because they can't just break applications. So even if the database changes to use opaque identifiers those installed systems will need to revert to the current system anyway. At the moment, the Linux LTS distros will be supported for at least another decade. Human behaviour would also be impacted, though to a lesser extent: it's not that hard to convert from typing "TZ=America/Los_Angeles date" to "TZ=$(find_timezone 'San Francisco') date" but a lot more people who complain about the various spellings of regions are going to ask wtf? That decade or so for the switch over is also going to be confusing. Systems will be using the current names but the master database will be using opaque identifiers and while a lot of us on this list will be fine with that, it's going to affect others as well. I think, even so, this will not fix the problem. Instead of complaining about the Europe/Kiev name, they'll be complaining about the spelling of the mapping from an opaque identifier to Europe/Kiev. Perhaps, as was suggested earlier, an in-your-face statement of "timezone identifiers use common English spellings of names" would at least slow down the rate of spelling correction messages. jch
On Oct 4, 2018, at 12:35, John Haxby <john.haxby@oracle.com> wrote:
I think, even so, this will not fix the problem. Instead of complaining about the Europe/Kiev name, they'll be complaining about the spelling of the mapping from an opaque identifier to Europe/Kiev.
Exactly. At *some* point in the chain, these zones need to get turned into geographical names that people can recognize. In some regions, that naming process is fraught with dispute and emotion; unfortunately, due to the very nature of what tzdb is and does, we are never going to be free from that aspect. Thus, changing the current identifiers would merely add confusion for users and complexity to the code without addressing the essence of the issue. That cartoon from Xkcd posted here last week [https://xkcd.com/2050/ <https://xkcd.com/2050/>] somehow feels relevant… :) Cheers! |----------------------------------------------------------------------| | Frederick F. Gleason, Jr. | Chief Developer | | | Paravel Systems | |----------------------------------------------------------------------| | A room without books is like a body without a soul. | | -- Cicero | |----------------------------------------------------------------------|
I suggested a completely backward compatible approach. Downstream consumers can have a form of the data that looks as it does now. The argument we are supposedly trying to make is that NOBODY should be presenting these names to users - they should be using the tzid as a key to a localized lookup so UI wise there's no difference. I don't think we can use 'misuse' of those names as a reason not to change. There is also the point that some are reluctant to use the Olson data at least because it's tied to politically sensitive names. Having the originators maintain a UID at least satisfies that problem. On 10/4/18 13:02, Fred Gleason wrote:
On Oct 4, 2018, at 12:35, John Haxby <john.haxby@oracle.com <mailto:john.haxby@oracle.com>> wrote:
I think, even so, this will not fix the problem. Instead of complaining about the Europe/Kiev name, they'll be complaining about the spelling of the mapping from an opaque identifier to Europe/Kiev.
Exactly. At *some* point in the chain, these zones need to get turned into geographical names that people can recognize. In some regions, that naming process is fraught with dispute and emotion; unfortunately, due to the very nature of what tzdb is and does, we are never going to be free from that aspect. Thus, changing the current identifiers would merely add confusion for users and complexity to the code without addressing the essence of the issue. Yes - these discussions are always fraught with dispute and emotion.
The point here is to distance this group that maintains the zone data from some other group that does localization. With a little care most consumers of the data won't see the difference.
That cartoon from Xkcd posted here last week [https://xkcd.com/2050/] somehow feels relevant… :)
I think that cartoon identifies the type of discussion that SHOULD take place in this group.
Cheers!
|----------------------------------------------------------------------| | Frederick F. Gleason, Jr. | Chief Developer | | | Paravel Systems | |----------------------------------------------------------------------| | A room without books is like a body without a soul. | | -- Cicero | |----------------------------------------------------------------------|
I happen to agree with Mike that the naming of the zones can be extracted out as meta-data to go along with the tz rulesets. The IANA db can use UUIDs, urns or whatever to label the zones and also provide a mapping from the current names to the opaque ids. Consumers of the data can use the existing mapping or create their own. On 10/04/2018 01:42 PM, Michael Douglass wrote:
I suggested a completely backward compatible approach.
Downstream consumers can have a form of the data that looks as it does now.
The argument we are supposedly trying to make is that NOBODY should be presenting these names to users - they should be using the tzid as a key to a localized lookup so UI wise there's no difference. I don't think we can use 'misuse' of those names as a reason not to change.
There is also the point that some are reluctant to use the Olson data at least because it's tied to politically sensitive names. Having the originators maintain a UID at least satisfies that problem.
On 10/4/18 13:02, Fred Gleason wrote:
On Oct 4, 2018, at 12:35, John Haxby <john.haxby@oracle.com <mailto:john.haxby@oracle.com>> wrote:
I think, even so, this will not fix the problem. Instead of complaining about the Europe/Kiev name, they'll be complaining about the spelling of the mapping from an opaque identifier to Europe/Kiev.
Exactly. At *some* point in the chain, these zones need to get turned into geographical names that people can recognize. In some regions, that naming process is fraught with dispute and emotion; unfortunately, due to the very nature of what tzdb is and does, we are never going to be free from that aspect. Thus, changing the current identifiers would merely add confusion for users and complexity to the code without addressing the essence of the issue. Yes - these discussions are always fraught with dispute and emotion.
The point here is to distance this group that maintains the zone data from some other group that does localization. With a little care most consumers of the data won't see the difference.
That cartoon from Xkcd posted here last week [https://xkcd.com/2050/] somehow feels relevant… :)
I think that cartoon identifies the type of discussion that SHOULD take place in this group.
Cheers!
|----------------------------------------------------------------------| | Frederick F. Gleason, Jr. | Chief Developer | | | Paravel Systems | |----------------------------------------------------------------------| | A room without books is like a body without a soul. | | -- Cicero | |----------------------------------------------------------------------|
-- Ken Murchison Cyrus Development Team FastMail US LLC
On Oct 4, 2018, at 2:37 PM, Ken Murchison <murch@fastmail.com> wrote:
I happen to agree with Mike that the naming of the zones can be extracted out as meta-data to go along with the tz rulesets. The IANA db can use UUIDs, urns or whatever to label the zones and also provide a mapping from the current names to the opaque ids. Consumers of the data can use the existing mapping or create their own.
I'm still not sure why there is a need to do a whole pile of work on the tzdb, merely to work around people who ignore the documentation. paul
On Oct 4, 6:41pm, Paul.Koning@dell.com (<Paul.Koning@dell.com>) wrote: -- Subject: Re: [tz] Rename Ukrainian cities to their official transliterated | I'm still not sure why there is a need to do a whole pile of work on the | tzdb, merely to work around people who ignore the documentation. I agree with Paul here; it is simpler to point the people who ignore the documentation at the documentation (educational for them too). The documentation is well written and provides both rationale and guidelines. I feel that anonymizing the identifiers will just make life more complicated for everyone in the name of some form of "<insert-adjective> correctness/sensitivity/vanity". christos
On 4 Oct 2018, at 18:42, Michael Douglass <mikeadouglass@gmail.com> wrote:
The argument we are supposedly trying to make is that NOBODY should be presenting these names to users - they should be using the tzid as a key to a localized lookup so UI wise there's no difference. I don't think we can use 'misuse' of those names as a reason not to change.
However, you cannot expect enterprise system providers to break current applications because of that 'misuse'. If you want to make the change then you need to deal with the fact that it's going to take at least a decade before the existing applications are no longer supported. During those 10 years or more you are going to have to keep dealing with those people who think that regions should be named differently. The better approach, I suspect, is to educate. jch
On Thu 2018-10-04T10:33:55-0400 Michael Douglass hath writ:
Kicking it up a level is exactly what's needed.
There are many approaches to this but separating the tz data from names is both simple and backward compatible with end consumers though it requires a little work to change the data and the tools which use that data.
I am going to disagree with this based on history. These sorts of arguments about responsibility, functionality, and international legal and bureaucratic issues are eerily similar to the process by which the world got leap seconds, with the responsibility for those split between multiple agencies in a way that utterly obscures what is the goal and who is in charge. Better to keep that all in one place that is clearly documented as to how it should and should not be used and where the alternatives are for folks who do not like the base form. -- Steve Allen <sla@ucolick.org> WGS-84 (GPS) UCO/Lick Observatory--ISB 260 Natural Sciences II, Room 165 Lat +36.99855 1156 High Street Voice: +1 831 459 3046 Lng -122.06015 Santa Cruz, CA 95064 http://www.ucolick.org/~sla/ Hgt +250 m
On Oct 4, 2018, at 1:11 PM, Steve Allen <sla@ucolick.org> wrote:
[EXTERNAL EMAIL] Please report any suspicious attachments, links, or requests for sensitive information.
On Thu 2018-10-04T10:33:55-0400 Michael Douglass hath writ:
Kicking it up a level is exactly what's needed.
There are many approaches to this but separating the tz data from names is both simple and backward compatible with end consumers though it requires a little work to change the data and the tools which use that data.
I am going to disagree with this based on history. These sorts of arguments about responsibility, functionality, and international legal and bureaucratic issues are eerily similar to the process by which the world got leap seconds, with the responsibility for those split between multiple agencies in a way that utterly obscures what is the goal and who is in charge. Better to keep that all in one place that is clearly documented as to how it should and should not be used and where the alternatives are for folks who do not like the base form.
True. But the whole timezone thing end to end, all the way to the user interface, is not intended to be managed in one place. The top end of TZDB is (intended to be) an internal interface, not a user interface. The problem is that some people don't bother to deliver the user interface and use the internal interface directly. That would be ok, except for the fact that they then complain that the encoding at the internal interface isn't user friendly. The answer is "no, and it isn't supposed to be, read the documentation". Unfortunately, it keeps coming up N times per year. And not everyone responds to the answer in the reasonable way that the requester did on this occasion. paul
On 10/4/18 7:33 AM, Michael Douglass wrote:
Opaque ids are what some consumers have been asking for for some time because of the political implications of the names.
I would rather not change the zone names currently used in tzdb source files, as the change would be a hassle for both maintainers and users, and the existing names simplify maintenance since they are easier to read than opaque IDs would be. Although we could add an auxiliary table that maps existing names to short, stable, and reasonably opaque identifiers, CLDR is already maintaining such a table and it'd be confusing if we attempted to duplicate that work; plus, such a table would not be useful to tzcode so it wouldn't be tested well by us. For now, we are probably better off improving the already-existing suggestion to use CLDR facilities for consumers worried about politics. Proposed patch attached.
On 10/4/18 16:00, Paul Eggert wrote:
On 10/4/18 7:33 AM, Michael Douglass wrote:
Opaque ids are what some consumers have been asking for for some time because of the political implications of the names.
I would rather not change the zone names currently used in tzdb source files, as the change would be a hassle for both maintainers and users, and the existing names simplify maintenance since they are easier to read than opaque IDs would be.
Although we could add an auxiliary table that maps existing names to short, stable, and reasonably opaque identifiers, CLDR is already maintaining such a table and it'd be confusing if we attempted to duplicate that work; plus, such a table would not be useful to tzcode so it wouldn't be tested well by us. For now, we are probably better off improving the already-existing suggestion to use CLDR facilities for consumers worried about politics. Proposed patch attached.
I believe this group should be the authoritative source for such an id. What happens when zones split etc? There's presumably a delay between the split and an appearance in cldr data. While we continue to provide only the name as the key to a zone people will continue to mistake it for something they can present to users. Criticizing such people isn't going to stop it. Not having a uid in the data means we have no choice but to use that 'human-readable' key. I'd propose adding a UID to VTIMEZONE - happy to write the spec - but at the moment there's no usable value.
Then again I would suggest putting relevant info in the readme or such instead of theory for visibility purpose. 在 2018年10月5日週五 04:00,Paul Eggert <eggert@cs.ucla.edu> 寫道:
On 10/4/18 7:33 AM, Michael Douglass wrote:
Opaque ids are what some consumers have been asking for for some time because of the political implications of the names.
I would rather not change the zone names currently used in tzdb source files, as the change would be a hassle for both maintainers and users, and the existing names simplify maintenance since they are easier to read than opaque IDs would be.
Although we could add an auxiliary table that maps existing names to short, stable, and reasonably opaque identifiers, CLDR is already maintaining such a table and it'd be confusing if we attempted to duplicate that work; plus, such a table would not be useful to tzcode so it wouldn't be tested well by us. For now, we are probably better off improving the already-existing suggestion to use CLDR facilities for consumers worried about politics. Proposed patch attached.
On 10/4/18 8:36 PM, Phake Nick wrote:
I would suggest putting relevant info in the readme or such instead of theory for visibility purpose.
I drafted some text along those lines, but after a cooling-off period I reread it and it sounded too negative. README is a high-level description of the project that should be welcoming, and putting something in there that boils down to "Don't waste our time trying to rename Asia/Shanghai" is off-putting. Even CONTRIBUTING is mostly too high-level for this sort of thing. However, CONTRIBUTING can suggest that if the contribution might be controversial then one should read theory.html first (and give a URL to theory.html). Also, while I'm at it, README can be reworked slightly. Proposed patch attached.
On Oct 5, 2018, at 1:01 PM, Paul Eggert <eggert@CS.UCLA.EDU> wrote:
[EXTERNAL EMAIL] Please report any suspicious attachments, links, or requests for sensitive information.
On 10/4/18 8:36 PM, Phake Nick wrote:
I would suggest putting relevant info in the readme or such instead of theory for visibility purpose.
I drafted some text along those lines, but after a cooling-off period I reread it and it sounded too negative. README is a high-level description of the project that should be welcoming, and putting something in there that boils down to "Don't waste our time trying to rename Asia/Shanghai" is off-putting. Even CONTRIBUTING is mostly too high-level for this sort of thing. However, CONTRIBUTING can suggest that if the contribution might be controversial then one should read theory.html first (and give a URL to theory.html).
The trouble is that it isn't necessarily obvious to those who haven't been exposed to things that renaming zones might be "controversial". Perhaps just describe the issue specifically: before proposing zone name changes, read the discussion about zone names in the theory file. paul
On Oct 4, 2018, at 1:00 PM, Paul Eggert <eggert@cs.ucla.edu> wrote:
Although we could add an auxiliary table that maps existing names to short, stable, and reasonably opaque identifiers, CLDR is already maintaining such a table and it'd be confusing if we attempted to duplicate that work; plus, such a table would not be useful to tzcode so it wouldn't be tested well by us. For now, we are probably better off improving the already-existing suggestion to use CLDR facilities for consumers worried about politics. Proposed patch attached.
That handles the "please change the spelling of the city name in the tzdb region ID" problem, but we should perhaps also emphasize that a UI should *not* treat the name that happens to be used in a tzdb region ID as *the* city to offer - it should offer other cities as well - to handle the "please pick a different city so people in {San Francisco, Beijing, ...} won't have to select {Los Angeles, Shanghai, ...}" problem.
On 10/4/18 9:58 PM, Guy Harris wrote:
we should perhaps also emphasize that a UI should*not* treat the name that happens to be used in a tzdb region ID as*the* city to offer - it should offer other cities as well - to handle the "please pick a different city so people in {San Francisco, Beijing, ...} won't have to select {Los Angeles, Shanghai, ...}" problem.
I drafted the attached that does something along those lines. It deliberately sticks to the Uzhhorod/Uzhgorod example instead of better-known disputes like Kyiv/Kiev, Beijing/Shanghai, and San Francisco/Los Angeles (don't get me started!), to try to lessen the number of readers that might be offended. It also mentions using a map, which is out of our scope and also can rile users (ask Microsoft about the India-Pakistan border...) but we might as well mention geolocation while we're in the neighborhood, so to speak.
Paul.Koning@dell.com wrote:
This exact topic has been discussed (and rejected) many times in the past, several times per year.
We can add a comment to the 'europe' file so that potential contributors can understand the issues better before proposing patches. Proposed patch attached. I just now did a Wikipedia search from Los Angeles, and "Uzhgorod" had about 2,860,000 hits whereas "Uzhhorod" had 1,040,000, so it seems that traditional English spellings are still holding strong for smaller Ukrainian cities as well.
03.10.18 20:07, Paul Eggert wrote:
Paul.Koning@dell.com wrote:
This exact topic has been discussed (and rejected) many times in the past, several times per year.
We can add a comment to the 'europe' file so that potential contributors can understand the issues better before proposing patches. Proposed patch attached.
I just now did a Wikipedia search from Los Angeles, and "Uzhgorod" had about 2,860,000 hits whereas "Uzhhorod" had 1,040,000, so it seems that traditional English spellings are still holding strong for smaller Ukrainian cities as well.
Thank you for looking into this. I wasn't careful enough to read that much of archives, only checked a few last month. Alas, mailing list archives are not that human friendly. So having a comment outlining current state and reasoning right at the `europe` would be most helpful. Adding a comment is probably the easiest way to nail down guys like me that are generally trying to fix obvious error (that what we think) and see no other attempts to do that logged in the same file. Probably a link to ftp://ftp.iana.org/tz/theory.html wouldn't harm too. Idea expressed by Guy Harris should go there too probably. Though I wouldn't agree with him completely it's worth mentioning in the first place. Outlining current status for Uzhhorod/Zaporizhzhia would be nice too, for example if you check Wikipedia you can find Zaporizhia as the most commonly used form. While taking some place in the comments this will direct people to some real qualifiers and will outline what should be done to change things. Big thanks for your time and looking into this. Hope after this changes the steady flow of patches will cease. :) -- Sphinx of black quartz judge my vow.
participants (16)
-
christos@zoulas.com -
David Patte -
Fred Gleason -
Guy Harris -
John Haxby -
Ken Murchison -
Lester Caine -
Michael Douglass -
Paul Eggert -
Paul.Koning@dell.com -
Paw Boel Nielsen -
Phake Nick -
Philip Paeps -
Steve Allen -
Tim Parenti -
Volodymyr Kostyrko