Hello, In all versions of TZ data Ukraine zones are named using Russian language transliteration (e.g Europe/Kiev, Europe/Uzhgorod, Europe/Zaporozhye). In *tzdata2016j* in file *europe *it is said *"Kyiv is the transliteration of the Ukrainian name, but "Kiev" is more common in English".* But this is a mistake, because *"more common"* is a very subjective measure and in this case is imposed by russian speaking community which is larger than ukrainian one. Believe that in most groups of Chinese language the mentioned names are pronounced differently from Russian transliteration(even if chinese speaking population is greater than russian one). The official language in Ukraine is Ukrainian, so the proper names of mentioned cities are Kyiv, Uzhhorod and Zaporizhia respectively. Who is responsible for editing this data? -- Regards, Maksym Besida.
On 11/30/2016 01:22 PM, Maksym Besida wrote:
/"more common"/ is a very subjective measure
It's true that this is to some extent subjective, but I'm afraid that's the best we can do. By the way, end users should not need to deal with English-language strings like "Kiev". Instead, they should be seeing translations like "Київ", "基辅", and (my favorite) "Kænugarður". These translations are maintained by CLDR. See: http://www.unicode.org/cldr/charts/latest/by_type/timezones.europe.html
TZ files are changed frequently because a country can pass a law, for example, not to use DST or some region of the country decides to move to other timezone. Why this also can not be changed according to the decree of Ukrainian authority <http://zakon3.rada.gov.ua/laws/show/55-2010-%D0%BF> (text in Ukrainian)? which states that names of geographical objects(and human names) must be transliterated according to the rules mentioned there. This was issued in 2010, from that time TZ database has been changed several times. When you're mentioning a user, could you please specify who do you mean? Because me, as a developer, have to use those russian transliterated names when I want to specify a time zones. Also a lot of libraries depends on the "truth" that is present in TZ database, and users of that libraries might get wrong impression of actual names of the geographical objects, specifically in Ukraine in our case but there are much more such cases for other countries/cities(can't defend them as do not know language policy for them). 2016-12-01 20:50 GMT+02:00 Paul Eggert <eggert@cs.ucla.edu>:
On 11/30/2016 01:22 PM, Maksym Besida wrote:
/"more common"/ is a very subjective measure
It's true that this is to some extent subjective, but I'm afraid that's the best we can do.
By the way, end users should not need to deal with English-language strings like "Kiev". Instead, they should be seeing translations like "Київ", "基辅", and (my favorite) "Kænugarður". These translations are maintained by CLDR. See:
http://www.unicode.org/cldr/charts/latest/by_type/timezones.europe.html
-- З повагою, Максим Бесіда.
On 12/01/2016 12:44 PM, Maksym Besida wrote:
TZ files are changed frequently because a country can pass a law
Sure, and that's because people change their clocks, which is the tz database subject matter. As much as possible we want to focus on the subject matter, and not be distracted by non-timekeeping issues such as whether a city's name should be "Jerusalem" or "al-Quds". We can't resolve political issues like that and we should not waste time trying.
When you're mentioning a user, could you please specify who do you mean? End users set their time zone on their cell phone or laptop or desktop or whatever, and their user interfaces should display translated names.
On Dec 1, 2016, at 1:07 PM, Paul Eggert <eggert@cs.ucla.edu> wrote:
On 12/01/2016 12:44 PM, Maksym Besida wrote:
TZ files are changed frequently because a country can pass a law
Sure, and that's because people change their clocks, which is the tz database subject matter. As much as possible we want to focus on the subject matter, and not be distracted by non-timekeeping issues such as whether a city's name should be "Jerusalem" or "al-Quds". We can't resolve political issues like that and we should not waste time trying.
When you're mentioning a user, could you please specify who do you mean? End users set their time zone on their cell phone or laptop or desktop or whatever, and their user interfaces should display translated names.
And that's "translated names of appropriate cities, even if they're not used as the cities in tzdb names". I.e., time zone selector programs should ***NOT*** ever show users tzdb names. (It would have been nice if there had been some form of ID that we could have used for tzdb zones that *didn't* involve city names, given all the opportunities for complaints that using city names has given.)
On 12/01/2016 01:30 PM, Guy Harris wrote:
It would have been nice if there had been some form of ID that we could have used for tzdb zones that*didn't* involve city names
How about SHA-256 checksums? Instead of "Europe/Kiev" the zone name would be "099d2adb7f9a187c25224cd49364de6d510d6e89924584c0b97d88d3f801e551", which would make users less likely to raise political objections. SHA3-512 is also a possibility, although SHA3 software isn't as mature and the names would be a bit long. (:-)
<<On Thu, 1 Dec 2016 13:46:39 -0800, Paul Eggert <eggert@cs.ucla.edu> said:
On 12/01/2016 01:30 PM, Guy Harris wrote:
It would have been nice if there had been some form of ID that we could have used for tzdb zones that*didn't* involve city names
How about SHA-256 checksums? Instead of "Europe/Kiev" the zone name would be "099d2adb7f9a187c25224cd49364de6d510d6e89924584c0b97d88d3f801e551", which would make users less likely to raise political objections.
A stable identifier is what's needed. What would that be the SHA-256 of? If it's a hash of the data, then you no longer have a stable identifier. -GAWollman
What is that a checksum of? The zone name? If we're moving away from zone names like that, I don't see any point in hashing an identifier just to obscure it. Better to just use an incrementing counter (Asia/009, America/010) or an algorithm that generates pronouncable names when fed an incrementing counter (Asia/009 -> Asia/Kasoma, America/010 -> America/Fureso). On December 1, 2016 4:46:39 PM EST, Paul Eggert <eggert@cs.ucla.edu> wrote:
On 12/01/2016 01:30 PM, Guy Harris wrote:
It would have been nice if there had been some form of ID that we could have used for tzdb zones that*didn't* involve city names
How about SHA-256 checksums? Instead of "Europe/Kiev" the zone name would be "099d2adb7f9a187c25224cd49364de6d510d6e89924584c0b97d88d3f801e551", which would make users less likely to raise political objections. SHA3-512 is also a possibility, although SHA3 software isn't as mature and the names would be a bit long. (:-)
On Dec 1, 2016, at 1:54 PM, Paul G <paul@ganssle.io> wrote:
What is that a checksum of? The zone name?
If we're moving away from zone names like that, I don't see any point in hashing an identifier just to obscure it. Better to just use an incrementing counter (Asia/009, America/010) or an algorithm that generates pronouncable names when fed an incrementing counter (Asia/009 -> Asia/Kasoma, America/010 -> America/Fureso).
And then get rid of the continent, so we don't get into arguments about whether Cyprus is part of Europe or Asia.
And tz's suggestion that Toronto is in America. On 2016-12-01 16:56, Guy Harris wrote:
On Dec 1, 2016, at 1:54 PM, Paul G <paul@ganssle.io> wrote:
What is that a checksum of? The zone name?
If we're moving away from zone names like that, I don't see any point in hashing an identifier just to obscure it. Better to just use an incrementing counter (Asia/009, America/010) or an algorithm that generates pronouncable names when fed an incrementing counter (Asia/009 -> Asia/Kasoma, America/010 -> America/Fureso). And then get rid of the continent, so we don't get into arguments about whether Cyprus is part of Europe or Asia.
--
On 1 Dec 2016, at 21:46, Paul Eggert <eggert@cs.ucla.edu> wrote:
On 12/01/2016 01:30 PM, Guy Harris wrote:
It would have been nice if there had been some form of ID that we could have used for tzdb zones that*didn't* involve city names
How about SHA-256 checksums? Instead of "Europe/Kiev" the zone name would be "099d2adb7f9a187c25224cd49364de6d510d6e89924584c0b97d88d3f801e551", which would make users less likely to raise political objections. SHA3-512 is also a possibility, although SHA3 software isn't as mature and the names would be a bit long. (:-)
You’d have to have an interim version that kept both the existing names and the hash while the various distros and platforms convert from their current selector to a selector that uses the hash names. You could be relatively draconian about this: provide the interim names for a little while and then leave it up to the long-lived distros and platforms to put the existing names back because that’s what the platforms and application software demands. For the sake of consistency among all those long-lived platforms (we’re talking at least decade before the various LTS’s stop providing tzdata updates) then it would be best if tzdata maintains the mapping table. It would probably be best to coordinate the initial change with CLDR so that they can maintain both the new (preferred) hashes and the old names during the transition decade. There would probably be a range of lucrative consulting projects as well to help people move from the old naming scheme to the new naming scheme and a selector that’s as good as the Apple one. I suspect that at some time during the transition decade that it will become apparent that the old names will need to be accessible one way or another for debugging and support purposes. (A user claims that 099d2…1e551 is the wrong timezone for their part of the world but investigation shows that this is the old Europe/Kiev timezone name and they live in Whitby. Yorkshire. England.) It would probably be a good idea to embed the old name in the binary file so that it can be easily retrieved. In fact this then gives a way for the diehards to revert to the old names. Unfortunately the diehard systems will then have Europe/Kiev instead of Europe/Kyiv so unfortunately we’ll still get complaints, albeit from a smaller group of people. Introducing a new timezone will require some coordination across the board. Out friend in Whitby (who runs on a different time to everyone else) will be using 4ccd94040a7d96dfb3a1a6b0e7db8d162e039515b09b73ec60fd7eb5bca3241b which will need to be added to CLDR at the same time it is invented so that the distro can update tzdata and the corresponding translation at the same time. I’m sure all that is doable the transition will be complete in a couple of decades and there will be hardly anyone using the old names and complaints about the embedded English names will be few and far between, or at least very much less than “I set my timezone to 4ccd94040a7d96dfb3a1a6b0e7db8d162e039515b09b73ec60fd7eb5bca3241 and the date shows as UTC what am I doing wrong?” On the other hand we could keep the status quo and continue to persuade the distros to use CLDR and provide a decent selector. I have a sneaking suspicious Paul wasn’t being entirely serious. If we could go back 30 years and use abstract names and build in internationalization from the outset then maybe it would have worked and CLDR wouldn’t need to deal with timezone names. With 20/20 hindsight we could probably design a system that would have worked in 1986 but I doubt it could have been designed then (Digital’s IPG was quite a new group and the stuff they were doing then was cutting edge.) jch
“I set my timezone to 4ccd94040a7d96dfb3a1a6b0e7db8d162e039515b09b73ec60fd7eb5bca3241 and the date shows as UTC what am I doing wrong?”
Every StackOverflow time zone question ever. From: John Haxby<mailto:john.haxby@oracle.com> Sent: Thursday, December 1, 2016 2:43 PM To: Paul Eggert<mailto:eggert@cs.ucla.edu> Cc: Time Zone Mailing List<mailto:tz@iana.org>; Maksym Besida<mailto:maks.besida@gmail.com> Subject: Re: [tz] Zone name policy On 1 Dec 2016, at 21:46, Paul Eggert <eggert@cs.ucla.edu<mailto:eggert@cs.ucla.edu>> wrote: On 12/01/2016 01:30 PM, Guy Harris wrote: It would have been nice if there had been some form of ID that we could have used for tzdb zones that*didn't* involve city names How about SHA-256 checksums? Instead of "Europe/Kiev" the zone name would be "099d2adb7f9a187c25224cd49364de6d510d6e89924584c0b97d88d3f801e551", which would make users less likely to raise political objections. SHA3-512 is also a possibility, although SHA3 software isn't as mature and the names would be a bit long. (:-) You’d have to have an interim version that kept both the existing names and the hash while the various distros and platforms convert from their current selector to a selector that uses the hash names. You could be relatively draconian about this: provide the interim names for a little while and then leave it up to the long-lived distros and platforms to put the existing names back because that’s what the platforms and application software demands. For the sake of consistency among all those long-lived platforms (we’re talking at least decade before the various LTS’s stop providing tzdata updates) then it would be best if tzdata maintains the mapping table. It would probably be best to coordinate the initial change with CLDR so that they can maintain both the new (preferred) hashes and the old names during the transition decade. There would probably be a range of lucrative consulting projects as well to help people move from the old naming scheme to the new naming scheme and a selector that’s as good as the Apple one. I suspect that at some time during the transition decade that it will become apparent that the old names will need to be accessible one way or another for debugging and support purposes. (A user claims that 099d2…1e551 is the wrong timezone for their part of the world but investigation shows that this is the old Europe/Kiev timezone name and they live in Whitby. Yorkshire. England.) It would probably be a good idea to embed the old name in the binary file so that it can be easily retrieved. In fact this then gives a way for the diehards to revert to the old names. Unfortunately the diehard systems will then have Europe/Kiev instead of Europe/Kyiv so unfortunately we’ll still get complaints, albeit from a smaller group of people. Introducing a new timezone will require some coordination across the board. Out friend in Whitby (who runs on a different time to everyone else) will be using 4ccd94040a7d96dfb3a1a6b0e7db8d162e039515b09b73ec60fd7eb5bca3241b which will need to be added to CLDR at the same time it is invented so that the distro can update tzdata and the corresponding translation at the same time. I’m sure all that is doable the transition will be complete in a couple of decades and there will be hardly anyone using the old names and complaints about the embedded English names will be few and far between, or at least very much less than “I set my timezone to 4ccd94040a7d96dfb3a1a6b0e7db8d162e039515b09b73ec60fd7eb5bca3241 and the date shows as UTC what am I doing wrong?” On the other hand we could keep the status quo and continue to persuade the distros to use CLDR and provide a decent selector. I have a sneaking suspicious Paul wasn’t being entirely serious. If we could go back 30 years and use abstract names and build in internationalization from the outset then maybe it would have worked and CLDR wouldn’t need to deal with timezone names. With 20/20 hindsight we could probably design a system that would have worked in 1986 but I doubt it could have been designed then (Digital’s IPG was quite a new group and the stuff they were doing then was cutting edge.) jch
On Thu, Dec 1, 2016 at 3:44 PM, Maksym Besida <maks.besida@gmail.com> wrote:
Because me, as a developer, have to use those russian transliterated names when I want to specify a time zones.
If that would provide any reconciliation, the tzdb adopted spelling of "Kiev" does not follow the official Russian transliteration rules either. Russian name "Киев" would be transliterated as "Kiyev" ("е" after a vowel is transliterated as "ye".) As others have mentioned already, tzdb does not use transliterated local names. It uses English names.
participants (9)
-
Alexander Belopolsky -
David Patte ₯ -
Garrett Wollman -
Guy Harris -
John Haxby -
Maksym Besida -
Matt Johnson -
Paul Eggert -
Paul G