Hello, Please be informed that your database has an error in naming Ukrainian city Kyiv. It is provided in the tz database as 'Kiev'. In June 2019 the name *Kyiv* was officially adopted by the United States Board on Geographic Names as the only correct one. Please correct the mistake Thank you
The name has been changed to Europe/Kyiv in the development version here: https://github.com/eggert/tz/commit/e13e9c531fc48a04fb8d064acccc9f8ae68d5544 and this should appear in the next TZDB release, whenever that happens to be (there is no schedule for it).
OK Why didn't you add my request to the messages list? There is only your reply without my request. ( https://mm.icann.org/pipermail/tz/2022-June/subject.html) пн, 27 июн. 2022 г. в 16:46, Paul Eggert <eggert@cs.ucla.edu>:
The name has been changed to Europe/Kyiv in the development version here:
https://github.com/eggert/tz/commit/e13e9c531fc48a04fb8d064acccc9f8ae68d5544
and this should appear in the next TZDB release, whenever that happens to be (there is no schedule for it).
Quoting Petro Ord via tz on Monday June 27, 2022:
OK Why didn't you add my request to the messages list? There is only your reply without my request. ( https://mm.icann.org/pipermail/tz/2022-June/subject.html)
When non-subscribers submit emails to the list, it goes into a moderation queue that the IANA team reviews, usually once a day. This is normal for public discussion lists, and is predominantly to filter out a significant number of spam messages attempted to be sent to this list. With that said, many of the recent submissions pertain to the same issues on the naming of Kyiv that have already been exhaustively discussed on this list in the past. If there are new submissions on the topic that don’t bring pertinent new information to the discussions, we plan not to let them through for now. kim
I have checked past discussions and all the answers are about Kyiv not being a common English word. If people are still writing to you about the same error it means your statement about "Kyiv is NOT a common word" is wrong. Pertinent is the number of such requests, and this number is unknown. Even when I wrote mine, I saw another one has submitted the same, which only states that it is not just a typo, it's a bug. пн, 27 июн. 2022 г. в 18:33, Kim Davies <kim.davies@iana.org>:
Quoting Petro Ord via tz on Monday June 27, 2022:
OK Why didn't you add my request to the messages list? There is only your reply without my request. ( https://mm.icann.org/pipermail/tz/2022-June/subject.html)
When non-subscribers submit emails to the list, it goes into a moderation queue that the IANA team reviews, usually once a day. This is normal for public discussion lists, and is predominantly to filter out a significant number of spam messages attempted to be sent to this list.
With that said, many of the recent submissions pertain to the same issues on the naming of Kyiv that have already been exhaustively discussed on this list in the past. If there are new submissions on the topic that don’t bring pertinent new information to the discussions, we plan not to let them through for now.
kim
On 27/06/2022 16:45, Petro Ord via tz wrote:
I have checked past discussions and all the answers are about Kyiv not being a common English word.
It wasn't until relatively recently, but has been gradually growing in popularity since 2018. With recent events in 2022 it appears to have become more popular than the old name in the English language (at least when referring to the Ukrainian capital city, and not when referring to chicken recipes where I suspect the old name is still more popular). That is why the current development version of the TZ database was updated on April 13 this year, and the change will appear in the next release.
If people are still writing to you about the same error it means your statement about "Kyiv is NOT a common word" is wrong. Pertinent is the number of such requests, and this number is unknown. Even when I wrote mine, I saw another one has submitted the same, which only states that it is not just a typo, it's a bug.
Changes to existing zone names are rare, and significant. You may consider it a bug, but it does not break anything, unlike changes to timekeeping rules. The old name still works. After the next version of the TZ database has been released and installed locally, people can switch over to using "Europe/Kyiv" if they want to. Until then, they should continue using the old name since that is the one that is installed. After release, the old name should also continue to work for backwards compatibility, at least on those distributions that do install the links from old names to new names. TZ releases do have hidden costs in the IT industry, so the maintainer only tends to do a new release when absolutely necessary but ideally allowing plenty of time for timekeeping rules to percolate through the various 3rd-party distributors to the end-user devices. Regrettably for you, name changes are not deemed important enough by themselves to require an expedited release. If a more urgent reason for a release comes along, the name change will be released at the same time. None of the above prohibits anyone from making and installing their own release. It just won't be the official release. -- -=( Ian Abbott <abbotti@mev.co.uk> || MEV Ltd. is a company )=- -=( registered in England & Wales. Regd. number: 02862268. )=- -=( Regd. addr.: S11 & 12 Building 67, Europa Business Park, )=- -=( Bird Hall Lane, STOCKPORT, SK3 0XA, UK. || www.mev.co.uk )=-
Theory and pragmatics of the tz code and data says to "Use mainstream English spelling", popular is not quite a synonym to mainstream. With that being said, Kyiv became mainstream in 1991. How can you evaluate significance of the existing zone names, if the requests and messages are neglected? Look at the answer I've got from Paul Eggart: "The list is being moderated to suppress spam by people who are repeatedly lobbying for the spelling change. I forgot that, and cc'ed to the list. I should have just replied to you privately." That is quite intolerable to all Ukrainians and Ukraine-related issues. And again, who is in charge to define the change to be important? If it is one person - what is the meaning of such discussions, if it is the community - then why is the "repeated' request ignored? пн, 27 июн. 2022 г. в 20:46, Ian Abbott <abbotti@mev.co.uk>:
On 27/06/2022 16:45, Petro Ord via tz wrote:
I have checked past discussions and all the answers are about Kyiv not being a common English word.
It wasn't until relatively recently, but has been gradually growing in popularity since 2018. With recent events in 2022 it appears to have become more popular than the old name in the English language (at least when referring to the Ukrainian capital city, and not when referring to chicken recipes where I suspect the old name is still more popular). That is why the current development version of the TZ database was updated on April 13 this year, and the change will appear in the next release.
If people are still writing to you about the same error it means your statement about "Kyiv is NOT a common word" is wrong. Pertinent is the number of such requests, and this number is unknown. Even when I wrote mine, I saw another one has submitted the same, which only states that it is not just a typo, it's a bug.
Changes to existing zone names are rare, and significant. You may consider it a bug, but it does not break anything, unlike changes to timekeeping rules. The old name still works. After the next version of the TZ database has been released and installed locally, people can switch over to using "Europe/Kyiv" if they want to. Until then, they should continue using the old name since that is the one that is installed. After release, the old name should also continue to work for backwards compatibility, at least on those distributions that do install the links from old names to new names.
TZ releases do have hidden costs in the IT industry, so the maintainer only tends to do a new release when absolutely necessary but ideally allowing plenty of time for timekeeping rules to percolate through the various 3rd-party distributors to the end-user devices. Regrettably for you, name changes are not deemed important enough by themselves to require an expedited release. If a more urgent reason for a release comes along, the name change will be released at the same time.
None of the above prohibits anyone from making and installing their own release. It just won't be the official release.
-- -=( Ian Abbott <abbotti@mev.co.uk> || MEV Ltd. is a company )=- -=( registered in England & Wales. Regd. number: 02862268. )=- -=( Regd. addr.: S11 & 12 Building 67, Europa Business Park, )=- -=( Bird Hall Lane, STOCKPORT, SK3 0XA, UK. || www.mev.co.uk )=-
On 27/06/2022 21:32, Petro Ord wrote:
Theory and pragmatics of the tz code and data says to "Use mainstream English spelling", popular is not quite a synonym to mainstream. With that being said, Kyiv became mainstream in 1991.
You may have considered it mainstream in 1991, but the English language media took its time catching up. I think the first mention on the mailing list that Europe/Kyiv might be preferable (but not a request for change) was this post: https://mm.icann.org/pipermail/tz/2007-May/014365.html Then we have to wait nearly another 7 years for a post from an actual Ukrainian (I presume their nationality from context) requesting a name change: https://mm.icann.org/pipermail/tz/2014-April/020837.html There has been a steady stream of requests on the list since then, but the position has always been that the most prevalent spelling in the English language should be used. That has been reviewed by the TZ Coordinator (a.k.a. the maintainer, Paul Eggert) and others several times over the intervening years and was finally deemed to have flipped over in favour of the Kyiv spelling earlier this year. It was always likely to happen sometime as the Kyiv spelling gradually gained in popularity.
How can you evaluate significance of the existing zone names, if the requests and messages are neglected? Look at the answer I've got from Paul Eggart: "The list is being moderated to suppress spam by people who are repeatedly lobbying for the spelling change. I forgot that, and cc'ed to the list. I should have just replied to you privately." That is quite intolerable to all Ukrainians and Ukraine-related issues.
I'm sure it saves a lot of bandwidth discussing a barrage of requests for a change already that was already under consideration as part of an ongoing review process. I'm sure most of those posters did not take the time to search through the archives of the mailing list for similar discussions. The ones that did, and had something new to add would have been let through.
And again, who is in charge to define the change to be important? If it is one person - what is the meaning of such discussions, if it is the community - then why is the "repeated' request ignored?
The answers to "who is in charge?" and general procedure questions is in RFC 6557 <https://www.rfc-editor.org/rfc/rfc6557.html>. -- -=( Ian Abbott <abbotti@mev.co.uk> || MEV Ltd. is a company )=- -=( registered in England & Wales. Regd. number: 02862268. )=- -=( Regd. addr.: S11 & 12 Building 67, Europa Business Park, )=- -=( Bird Hall Lane, STOCKPORT, SK3 0XA, UK. || www.mev.co.uk )=-
It probably won't help to keep explaining the same thing over and over again. Maybe if we quit paying attention to them, they'll go away. --Bill Seymour On Tue, Jun 28, 2022 at 5:46 AM Ian Abbott via tz <tz@iana.org> wrote:
On 27/06/2022 21:32, Petro Ord wrote:
Theory and pragmatics of the tz code and data says to "Use mainstream English spelling", popular is not quite a synonym to mainstream. With that being said, Kyiv became mainstream in 1991.
You may have considered it mainstream in 1991, but the English language media took its time catching up.
I think the first mention on the mailing list that Europe/Kyiv might be preferable (but not a request for change) was this post:
https://mm.icann.org/pipermail/tz/2007-May/014365.html
Then we have to wait nearly another 7 years for a post from an actual Ukrainian (I presume their nationality from context) requesting a name change:
https://mm.icann.org/pipermail/tz/2014-April/020837.html
There has been a steady stream of requests on the list since then, but the position has always been that the most prevalent spelling in the English language should be used. That has been reviewed by the TZ Coordinator (a.k.a. the maintainer, Paul Eggert) and others several times over the intervening years and was finally deemed to have flipped over in favour of the Kyiv spelling earlier this year. It was always likely to happen sometime as the Kyiv spelling gradually gained in popularity.
How can you evaluate significance of the existing zone names, if the requests and messages are neglected? Look at the answer I've got from Paul Eggart: "The list is being moderated to suppress spam by people who are repeatedly lobbying for the spelling change. I forgot that, and cc'ed to the list. I should have just replied to you privately." That is quite intolerable to all Ukrainians and Ukraine-related issues.
I'm sure it saves a lot of bandwidth discussing a barrage of requests for a change already that was already under consideration as part of an ongoing review process. I'm sure most of those posters did not take the time to search through the archives of the mailing list for similar discussions. The ones that did, and had something new to add would have been let through.
And again, who is in charge to define the change to be important? If it is one person - what is the meaning of such discussions, if it is the community - then why is the "repeated' request ignored?
The answers to "who is in charge?" and general procedure questions is in RFC 6557 <https://www.rfc-editor.org/rfc/rfc6557.html>.
-- -=( Ian Abbott <abbotti@mev.co.uk> || MEV Ltd. is a company )=- -=( registered in England & Wales. Regd. number: 02862268. )=- -=( Regd. addr.: S11 & 12 Building 67, Europa Business Park, )=- -=( Bird Hall Lane, STOCKPORT, SK3 0XA, UK. || www.mev.co.uk )=-
Bill Seymour via tz wrote:
It probably won't help to keep explaining the same thing over and over again. Maybe if we quit paying attention to them, they'll go away.
Hm, I wonder what you guys would do if your country was attacked by an aggressor. The whole discussion if and why to change the spelling to Kyiv is obsolete if the change has already been made in the repo, and even though usually a new version of the DB is only released if some TZ rule was changed, it should not be too hard to simply release a new version now, due to the specific situation, and don't wait until another country decides to stick with or abolish DST. I'm sure this would calm down this discussion immediately. Martin -- Martin Burnicki Senior Software Engineer MEINBERG Funkuhren GmbH & Co. KG Email: martin.burnicki@meinberg.de Phone: +49 5281 9309-414 Linkedin: https://www.linkedin.com/in/martinburnicki/ Lange Wand 9, 31812 Bad Pyrmont, Germany Amtsgericht Hannover 17HRA 100322 Geschäftsführer/Managing Directors: Günter Meinberg, Werner Meinberg, Andre Hartmann, Heiko Gerstung Websites: https://www.meinberg.de https://www.meinbergglobal.com
Hi, On 28.06.22 14:54, Martin Burnicki via tz wrote:
Bill Seymour via tz wrote:
It probably won't help to keep explaining the same thing over and over again. Maybe if we quit paying attention to them, they'll go away.
Hm, I wonder what you guys would do if your country was attacked by an aggressor.
Nowhere in the Theory file does it say, “make a change to a database key because we want to take sides in a war.” Good thing, too, or the list would really explode.
The whole discussion if and why to change the spelling to Kyiv is obsolete if the change has already been made in the repo
You should have stopped there.
, and even though usually a new version of the DB is only released if some TZ rule was changed, it should not be too hard to simply release a new version now, due to the specific situation, and don't wait until another country decides to stick with or abolish DST.
Absolutely not. That invites abuse down the line. El
Nowhere in the Theory file does it say, “make a change to a database key because we want to take sides in a war.” Good thing, too, or the list would really explode.
The Crimea time zone was rather quickly updated and added to the upcoming release in 2014, especially considering that Crimea is internationally recognized as being part of Ukraine. I don't think it was guided by the Theory file. ср, 29 июн. 2022 г. в 08:58, Eliot Lear via tz <tz@iana.org>:
Hi,
On 28.06.22 14:54, Martin Burnicki via tz wrote:
Bill Seymour via tz wrote:
It probably won't help to keep explaining the same thing over and over again. Maybe if we quit paying attention to them, they'll go away.
Hm, I wonder what you guys would do if your country was attacked by an aggressor.
Nowhere in the Theory file does it say, “make a change to a database key because we want to take sides in a war.” Good thing, too, or the list would really explode.
The whole discussion if and why to change the spelling to Kyiv is obsolete if the change has already been made in the repo
You should have stopped there.
, and even though usually a new version of the DB is only released if some TZ rule was changed, it should not be too hard to simply release a new version now, due to the specific situation, and don't wait until another country decides to stick with or abolish DST.
Absolutely not. That invites abuse down the line.
El
Petro, On 29.06.22 10:55, Petro Ord wrote:
Nowhere in the Theory file does it say, “make a change to a database key because we want to take sides in a war.” Good thing, too, or the list would really explode. The Crimea time zone was rather quickly updated and added to the upcoming release in 2014, especially considering that Crimea is internationally recognized as being part of Ukraine. I don't think it was guided by the Theory file.
The difference between the two has been explained on the list. Please read and internalize that explanation. In the meantime, have you reviewed what the OSes actually present as the TZ name? I note that MacOS presents both. Eliot
The difference between the two has been explained on the list. Please read and internalize that explanation. In the meantime, have you reviewed what the OSes actually present as the TZ name? I note that MacOS presents both.
Could you please be more specific and provide an example? ср, 29 июн. 2022 г. в 12:14, Eliot Lear <lear@lear.ch>:
Petro,
On 29.06.22 10:55, Petro Ord wrote:
Nowhere in the Theory file does it say, “make a change to a database key because we want to take sides in a war.” Good thing, too, or the list would really explode. The Crimea time zone was rather quickly updated and added to the upcoming release in 2014, especially considering that Crimea is internationally recognized as being part of Ukraine. I don't think it was guided by the Theory file.
The difference between the two has been explained on the list. Please read and internalize that explanation. In the meantime, have you reviewed what the OSes actually present as the TZ name? I note that MacOS presents both.
Eliot
On 29.06.22 12:17, Petro Ord wrote:
The difference between the two has been explained on the list. Please read and internalize that explanation. In the meantime, have you reviewed what the OSes actually present as the TZ name? I note that MacOS presents both. Could you please be more specific and provide an example?
MacOS 12.3.1 will take as input Kyiv and Kiev. This is also true for certain older releases, I believe. And this is a key point: most modern operating systems don't simply present or allow only the distributed database keys. Eliot
MacOS 12.3.1 will take as input Kyiv and Kiev. This is also true for certain older releases, I believe. And this is a key point: most modern operating systems don't simply present or allow only the distributed database keys.
It depends upon the provider of the service. For example, IBM overrides data to show only Europe/Kyiv (at least this what I see from Ukraine). ср, 29 июн. 2022 г. в 14:21, Eliot Lear <lear@lear.ch>:
On 29.06.22 12:17, Petro Ord wrote:
The difference between the two has been explained on the list. Please read and internalize that explanation. In the meantime, have you reviewed what the OSes actually present as the TZ name? I note that MacOS presents both.
Could you please be more specific and provide an example?
MacOS 12.3.1 will take as input Kyiv and Kiev. This is also true for certain older releases, I believe. And this is a key point: most modern operating systems don't simply present or allow only the distributed database keys.
Eliot
"Eliot" == Eliot Lear via tz <tz@iana.org> writes:
Eliot> The difference between the two has been explained on the Eliot> list. Please read and internalize that explanation. In the Eliot> meantime, have you reviewed what the OSes actually present as the Eliot> TZ name? I note that MacOS presents both. I just experimented, and apparently, MacOS no longer accepts Kiev, only Kyiv. Score one for the petitioners. :) -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/> Perl/Dart/Flutter consulting, Technical writing, Comedy, etc. etc. Still trying to think of something clever for the fourth line of this .sig
Randal L. Schwartz wrote:
I just experimented, and apparently, MacOS no longer accepts Kiev, only Kyiv. Score one for the petitioners. :)
If this means that macOS accepts "Europe/Kyiv" as a tz-style time zone, but does not support "Europe/Kiev", then this would be a very unusual sort of breaking change, since no tz database version beyond 2022a has been released yet. If this is about UI strings, then it is not related to the tz database or the pending change. -- Doug Ewell, CC, ALB | Lakewood, CO, US | ewellic.org
"Doug" == Doug Ewell <doug@ewellic.org> writes:
Doug> If this is about UI strings, then it is not related to the tz Doug> database or the pending change. Ahh. Yes, it was about UI strings. However, the listing of tz in macos 12.4 via sudo systemsetup -listtimezones is still (for Europe/K*): Europe/Kaliningrad Europe/Kiev Europe/Kirov Doug> -- Doug> Doug Ewell, CC, ALB | Lakewood, CO, US | ewellic.org -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/> Perl/Dart/Flutter consulting, Technical writing, Comedy, etc. etc. Still trying to think of something clever for the fourth line of this .sig
On Jun 30, 2022, at 10:31 AM, Randal L. Schwartz via tz <tz@iana.org> wrote:
However, the listing of tz in macos 12.4 via sudo systemsetup -listtimezones
(Or just ls /usr/share/zoneinfo/Europe/K* if you just want to cut straight through to Unix, don't want to run a command with root privileges, or don't want to have to pipe to some flavor of grep to extract the tzdb region names of interest.)
On Jun 30, 2022, at 10:26 AM, Doug Ewell via tz <tz@iana.org> wrote:
Randal L. Schwartz wrote:
I just experimented, and apparently, MacOS no longer accepts Kiev, only Kyiv. Score one for the petitioners. :)
If this means that macOS accepts "Europe/Kyiv" as a tz-style time zone, but does not support "Europe/Kiev",
It doesn't. See my email, and: $ date Thu Jun 30 10:51:34 PDT 2022 $ TZ=UTC0 date Thu Jun 30 17:51:38 UTC 2022 $ TZ=Europe/Kiev date Thu Jun 30 20:51:50 EEST 2022 $ TZ=Europe/Kyiv date Thu Jun 30 17:51:55 UTC 2022 (Any UN*X that has a list of cities in its time zone chooser should offer a "tzchooser" command, or something such as that, that takes a city name as an argument, with other region information provided as necessary, and outputs the appropriate tzdb region name, so the user can do something such as TZ=`citychooser Kyiv` date or TZ=`citychooser Paris TX` date and get the right answer.)
then this would be a very unusual sort of breaking change, since no tz database version beyond 2022a has been released yet.
And Apple don't ship it yet.
If this is about UI strings,
It is.
then it is not related to the tz database or the pending change.
It is, indeed, not related to the tz database or the pending change, as per my earlier email.
On Jun 30, 2022, at 11:26:03, Doug Ewell via tz wrote:
Randal L. Schwartz wrote:
I just experimented, and apparently, MacOS no longer accepts Kiev, only Kyiv. Score one for the petitioners. :)
I'm astonished.
If this means that macOS accepts "Europe/Kyiv" as a tz-style time zone, but does not support "Europe/Kiev", then this would be a very unusual sort of breaking change, since no tz database version beyond 2022a has been released yet.
Generally, the historic name is preserved with a symbolic link. Peculiarly, MacOS doesn't use symlinks in zoneinfo but replicates the files, despite that MacOS freely uses symlinks elsewhere. The extra storage is inconsequential. But, still, perhaps Deborah Goldsmith can relieve my puzzlement. -- gil
On Jun 30, 2022, at 11:55 AM, Paul Gilmartin via tz <tz@iana.org> wrote:
On Jun 30, 2022, at 11:26:03, Doug Ewell via tz wrote:
Randal L. Schwartz wrote:
I just experimented, and apparently, MacOS no longer accepts Kiev, only Kyiv. Score one for the petitioners. :)
I'm astonished.
I just figured he tried the "closest city" picker rather than looking at /usr/share/zoneinfo; that is, in fact, what happened. The closest city" picker, blessedly, does not do anything silly such as using the tree under /usr/share/zoneinfo as a list of choices. Would that more systems also avoided doing that.
If this means that macOS accepts "Europe/Kyiv" as a tz-style time zone, but does not support "Europe/Kiev", then this would be a very unusual sort of breaking change, since no tz database version beyond 2022a has been released yet.
Generally, the historic name is preserved with a symbolic link.
Peculiarly, MacOS doesn't use symlinks in zoneinfo but replicates the files, despite that MacOS freely uses symlinks elsewhere.
The extra storage is inconsequential. But, still, perhaps Deborah Goldsmith can relieve my puzzlement.
See my email. "Kyiv" and not "Kiev" is what the Apple "closest city" picker in 13.0 beta 2 (and, presumably, 12.4 - 12.3.1 accepts both) supports when choosing a time zone. Its tzdb still has Europe/Kiev but not Europe/Kyiv. When the next tzdb release comes out, and Apple provides it, the historic name will presumably be preserved either with a symlink or a copy. (Deborah, any idea why symlinks aren't used? /usr/share/zoneinfo, on 12.3.1, is a symlink to /var/db/timezone/zoneinfo, and /var/db/timezone/zoneinfo is, in turn, a symlink to /var/db/timezone/tz/2022a.1.0/zoneinfo, so it's not as if there's a complete refusal to use symlinks there.)
On Jun 30, 2022, at 6:52 AM, Randal L. Schwartz via tz <tz@iana.org> wrote:
"Eliot" == Eliot Lear via tz <tz@iana.org> writes:
Eliot> The difference between the two has been explained on the Eliot> list. Please read and internalize that explanation. In the Eliot> meantime, have you reviewed what the OSes actually present as the Eliot> TZ name? I note that MacOS presents both.
I just experimented, and apparently, MacOS no longer accepts Kiev, only Kyiv. Score one for the petitioners. :)
On the other hand: macOS 13.0 beta 2: $ ls -1 /usr/share/zoneinfo/Europe/K* /usr/share/zoneinfo/Europe/Kaliningrad /usr/share/zoneinfo/Europe/Kiev /usr/share/zoneinfo/Europe/Kirov $ However, in the "Date & Time" part of System Settings (the shiny new "let's make it more like iOS" name for the setting); 1) it recognizes "Kyiv" as a city, even though that's not in the /usr/share/zoneinfo/Europe directory; 2) it does not recognize "Kiev" as a city, even though that *is* in the /usr/share/zoneinfo/Europe directory; 3) it recognizes "Kharkiv" as a city, even though that's not in the /usr/share/zoneinfo/Europe directory; so the list of cities supported by the "Closest city" picker in "Date & Time" in macOS is *not* based on the contents of /usr/share/zoneinfo in macOS. (Either you're using a macOS 13 beta or you're using macOS 12.4; my Monterey VM is currently running 12.3.1, and it accepts both "Kyiv" and "Kiev" in its time zone city chooser. It's currently downloading the 12.4 update.) I didn't try setting either of them to Russian as the system language; I suspect the city chooser would accept Киев when the system language is Russian. (I.e., what the closest city chooser accepts is not just a list of path names underneath /usr/share/zoneinfo, and it's probably not even based on what path names exist there - there's probably lists of cities in various languages, with maps from those city names to tzdb regions. THAT IS A FEATURE, NOT A BUG. MOST TIME ZONE CHOOSERS SHOULD WORK THAT WAY.)
On 29/06/2022 09:55, Petro Ord via tz wrote:
The Crimea time zone was rather quickly updated and added to the upcoming release in 2014, especially considering that Crimea is internationally recognized as being part of Ukraine. I don't think it was guided by the Theory file.
Time zones are added/updated for pragmatic reasons to reflect the history of actual wall clock time in a particular region, not for idealogical reasons. See these comments in the "europe" file for Europe/Simferopol: # From Alexander Krivenyshev (2014-03-17): # time change at 2:00 (2am) on March 30, 2014 # https://vz.ru/news/2014/3/17/677464.html # From Paul Eggert (2014-03-30): # Simferopol and Sevastopol reportedly changed their central town clocks # late the previous day, but this appears to have been ceremonial # and the discrepancies are small enough to not worry about. And from the Theory file: | Most timezones correspond to a notable location and the database | records all known clock transitions for that location; some | timezones correspond instead to a fixed UTC offset. -- -=( Ian Abbott <abbotti@mev.co.uk> || MEV Ltd. is a company )=- -=( registered in England & Wales. Regd. number: 02862268. )=- -=( Regd. addr.: S11 & 12 Building 67, Europa Business Park, )=- -=( Bird Hall Lane, STOCKPORT, SK3 0XA, UK. || www.mev.co.uk )=-
Time zones are added/updated for pragmatic reasons to reflect the history of actual wall clock time in a particular region, not for idealogical reasons. See these comments in the "europe" file for Europe/Simferopol:
Exactly, the time zone was updated in accordance to russian news about the territory that does not belong to them (all the news links are russian). The fact that Ukraine did not change or agreed to change the time on that territory was not considered. # Simferopol and Sevastopol reportedly changed their central town clocks this is form russian news ср, 29 июн. 2022 г. в 12:32, Ian Abbott <abbotti@mev.co.uk>:
On 29/06/2022 09:55, Petro Ord via tz wrote:
The Crimea time zone was rather quickly updated and added to the upcoming release in 2014, especially considering that Crimea is internationally recognized as being part of Ukraine. I don't think it was guided by the Theory file.
Time zones are added/updated for pragmatic reasons to reflect the history of actual wall clock time in a particular region, not for idealogical reasons. See these comments in the "europe" file for Europe/Simferopol:
# From Alexander Krivenyshev (2014-03-17): # time change at 2:00 (2am) on March 30, 2014 # https://vz.ru/news/2014/3/17/677464.html # From Paul Eggert (2014-03-30): # Simferopol and Sevastopol reportedly changed their central town clocks # late the previous day, but this appears to have been ceremonial # and the discrepancies are small enough to not worry about.
And from the Theory file:
| Most timezones correspond to a notable location and the database | records all known clock transitions for that location; some | timezones correspond instead to a fixed UTC offset.
-- -=( Ian Abbott <abbotti@mev.co.uk> || MEV Ltd. is a company )=- -=( registered in England & Wales. Regd. number: 02862268. )=- -=( Regd. addr.: S11 & 12 Building 67, Europa Business Park, )=- -=( Bird Hall Lane, STOCKPORT, SK3 0XA, UK. || www.mev.co.uk )=-
On 29/06/2022 10:49, Petro Ord wrote:
Time zones are added/updated for pragmatic reasons to reflect the history of actual wall clock time in a particular region, not for idealogical reasons. See these comments in the "europe" file for Europe/Simferopol:
Exactly, the time zone was updated in accordance to russian news about the territory that does not belong to them (all the news links are russian). The fact that Ukraine did not change or agreed to change the time on that territory was not considered.
# Simferopol and Sevastopol reportedly changed their central town clocks this is form russian news
As far as I can tell, there have been no reports that the wrong time was shown for Europe/Simferopol during winter time (when its local time differs from Europe/Kyiv). -- -=( Ian Abbott <abbotti@mev.co.uk> || MEV Ltd. is a company )=- -=( registered in England & Wales. Regd. number: 02862268. )=- -=( Regd. addr.: S11 & 12 Building 67, Europa Business Park, )=- -=( Bird Hall Lane, STOCKPORT, SK3 0XA, UK. || www.mev.co.uk )=-
As far as I can tell, there have been no reports that the wrong time was shown for Europe/Simferopol during winter time (when its local time differs from Europe/Kyiv).
Valid point - I'll make one during winter time in order to be more specific on the problem issued. # From Alexander Krivenyshev (2014-03-17): # time change at 2:00 (2am) on March 30, 2014 # https://vz.ru/news/2014/3/17/677464.html # From Paul Eggert (2014-03-30): # Simferopol and Sevastopol reportedly changed their central town clocks I do not see this request complaining that the time was incorrect. The request implies that russia decided to change the time on the territory that does not belong to russia. I thought that tz update decisions should not be done upon political and/or ideological reasons, but, apparently, it does not apply to russian requests. ср, 29 июн. 2022 г. в 15:54, Ian Abbott <abbotti@mev.co.uk>:
On 29/06/2022 10:49, Petro Ord wrote:
Time zones are added/updated for pragmatic reasons to reflect the history of actual wall clock time in a particular region, not for idealogical reasons. See these comments in the "europe" file for Europe/Simferopol:
Exactly, the time zone was updated in accordance to russian news about the territory that does not belong to them (all the news links are russian). The fact that Ukraine did not change or agreed to change the time on that territory was not considered.
# Simferopol and Sevastopol reportedly changed their central town clocks this is form russian news
As far as I can tell, there have been no reports that the wrong time was shown for Europe/Simferopol during winter time (when its local time differs from Europe/Kyiv).
-- -=( Ian Abbott <abbotti@mev.co.uk> || MEV Ltd. is a company )=- -=( registered in England & Wales. Regd. number: 02862268. )=- -=( Regd. addr.: S11 & 12 Building 67, Europa Business Park, )=- -=( Bird Hall Lane, STOCKPORT, SK3 0XA, UK. || www.mev.co.uk )=-
On 29/06/2022 14:27, Petro Ord wrote:
As far as I can tell, there have been no reports that the wrong time was shown for Europe/Simferopol during winter time (when its local time differs from Europe/Kyiv).
Valid point - I'll make one during winter time in order to be more specific on the problem issued.
Corrections for times in the past are also welcome (e.g. for last winter), but note that "the wrong time" means that the local time indicated for the zone differs from the actual time that people in that region lived their lives by, e.g. transport departure and arrival times, store opening and closing times, work day start and end times, TV and radio programme start and end times, etc.
# From Alexander Krivenyshev (2014-03-17): # time change at 2:00 (2am) on March 30, 2014 # https://vz.ru/news/2014/3/17/677464.html # From Paul Eggert (2014-03-30): # Simferopol and Sevastopol reportedly changed their central town clocks
I do not see this request complaining that the time was incorrect. The request implies that russia decided to change the time on the territory that does not belong to russia. I thought that tz update decisions should not be done upon political and/or ideological reasons, but, apparently, it does not apply to russian requests.
When Ukraine successfully reclaims the occupied territory I assume one thing they will do is revert the local time back to Ukrainian standards, and the TZ entry for Europe/Simferopol will be updated to reflect that. It's not about supporting one side or another, it's about reflecting the actual situation on the ground. The historical parts of the TZ database contain several entries for time changes imposed by German occupying forces during WWII for example. -- -=( Ian Abbott <abbotti@mev.co.uk> || MEV Ltd. is a company )=- -=( registered in England & Wales. Regd. number: 02862268. )=- -=( Regd. addr.: S11 & 12 Building 67, Europa Business Park, )=- -=( Bird Hall Lane, STOCKPORT, SK3 0XA, UK. || www.mev.co.uk )=-
Corrections for times in the past are also welcome (e.g. for last winter), but note that "the wrong time" means that the local time indicated for the zone differs from the actual time that people in that region lived their lives by, e.g. transport departure and arrival times, store opening and closing times, work day start and end times, TV and radio programme start and end times, etc.
Fascinating how requirements differ for countries. For Crimea update a notice was enough
Alexander Krivenyshev wrote: http://voiceofrussia.com/news/2014_03_17/Crimea-to-switch-to-Moscow-Time-as- of-March-30-8334/ Thanks for the heads-up. That notice says that they'll switch to Moscow Time at 2pm, which means they'd advance their clocks by an hour once at 01:00 UTC (03:00 local time) and once again at 14:00 local time.
No transport departure and arrival times, no store opening and closing times, no work day start and end times, no TV and radio programme start and end times, etc., just a notice will do. Is the news about russia revoking Lithuania independence a valid notice? https://www.lrt.lt/en/news-in-english/19/1714852/russia-s-duma-mulls-revokin...
When Ukraine successfully reclaims the occupied territory I assume one thing they will do is revert the local time back to Ukrainian standards United Nations General Assembly Resolution 68/262 adopted on 27 March 2014 affirmed the General Assembly's commitment to the territorial integrity of Ukraine within its internationally recognized borders and underscored the invalidity of the 2014 Crimean referendum.
What will you do if russia decides to change time in Mariupol and Kherson? Will the answer be that theory.html says, "If boundaries between regions are fluid, such as during a war or insurrection, do not bother to create a new timezone merely because of yet another boundary change." (https://mm.icann.org/pipermail/tz/2022-May/031414.html) So the question ``Why are some changes done fast while Kyiv not Kiev errors remained unseen?" is open. ср, 29 июн. 2022 г. в 18:01, Ian Abbott <abbotti@mev.co.uk>:
On 29/06/2022 14:27, Petro Ord wrote:
As far as I can tell, there have been no reports that the wrong time was shown for Europe/Simferopol during winter time (when its local time differs from Europe/Kyiv).
Valid point - I'll make one during winter time in order to be more specific on the problem issued.
Corrections for times in the past are also welcome (e.g. for last winter), but note that "the wrong time" means that the local time indicated for the zone differs from the actual time that people in that region lived their lives by, e.g. transport departure and arrival times, store opening and closing times, work day start and end times, TV and radio programme start and end times, etc.
# From Alexander Krivenyshev (2014-03-17): # time change at 2:00 (2am) on March 30, 2014 # https://vz.ru/news/2014/3/17/677464.html # From Paul Eggert (2014-03-30): # Simferopol and Sevastopol reportedly changed their central town clocks
I do not see this request complaining that the time was incorrect. The request implies that russia decided to change the time on the territory that does not belong to russia. I thought that tz update decisions should not be done upon political and/or ideological reasons, but, apparently, it does not apply to russian requests.
When Ukraine successfully reclaims the occupied territory I assume one thing they will do is revert the local time back to Ukrainian standards, and the TZ entry for Europe/Simferopol will be updated to reflect that. It's not about supporting one side or another, it's about reflecting the actual situation on the ground. The historical parts of the TZ database contain several entries for time changes imposed by German occupying forces during WWII for example.
-- -=( Ian Abbott <abbotti@mev.co.uk> || MEV Ltd. is a company )=- -=( registered in England & Wales. Regd. number: 02862268. )=- -=( Regd. addr.: S11 & 12 Building 67, Europa Business Park, )=- -=( Bird Hall Lane, STOCKPORT, SK3 0XA, UK. || www.mev.co.uk )=-
On Jun 29, 2022, at 10:17 AM, Petro Ord via tz <tz@iana.org> wrote:
Is the news about russia revoking Lithuania independence a valid notice? https://www.lrt.lt/en/news-in-english/19/1714852/russia-s-duma-mulls-revokin...
It's a notice that a member of the Duma has submitted a bill to revoke the resolution “On Recognising the Independence of the Republic of Lithuania”. It's not yet a law, so Russia has not revoked Lithuanian independence. And changing the time observed in Lithuania will take more than a bill being passed by the Duma and a signature of that bill by the President of Russia, it would also require a successful occupation of a NATO member by Russia. So it's not a notice relevant to the tzdb.
When Ukraine successfully reclaims the occupied territory I assume one thing they will do is revert the local time back to Ukrainian standards United Nations General Assembly Resolution 68/262 adopted on 27 March 2014 affirmed the General Assembly's commitment to the territorial integrity of Ukraine within its internationally recognized borders and underscored the invalidity of the 2014 Crimean referendum.
What affect has the resolution had on the time to which Crimean residents set their watches and that Crimean residents expect their mobile phones/computing devices to display?
What will you do if russia decides to change time in Mariupol and Kherson? Will the answer be that theory.html says, "If boundaries between regions are fluid, such as during a war or insurrection, do not bother to create a new timezone merely because of yet another boundary change." (https://mm.icann.org/pipermail/tz/2022-May/031414.html)
Possibly. Unlike the Europe/Simferopol tzdb region, which had different time zone rules post-1970 and prior to the Russian occupation, Mariupol and Kherson were, I presume, on Kyiv time, so a time change there would require the creation of a new tzdb region.
So the question ``Why are some changes done fast while Kyiv not Kiev errors remained unseen?" is open.
Because that's not a change that affects time conversion. It's like the change from Asia/Calcutta to Asia/Kolkata; the city's name was changed in 2000 or 2001, to match the pronunciation in Bengali, and the tzdb name change occurred on 2008. That name change occurred in the tzdata2008b release, which also included a number of changes that *did* affect time conversion; it wasn't a release that *solely* changed tzdb region names.
It seems that "If boundaries between regions are fluid, such as during a war or insurrection, do not bother to create a new timezone merely because of yet another boundary change." does not apply to russia. Even more, it doesn't even matter what the other countries do or issue, except russia.What affect has the resolution had on the time to which Crimean residents set their watches and that Crimean residents expect their mobile phones/computing devices to display?
What affect has the resolution had on the time to which Crimean residents set their watches and that Crimean residents expect their mobile phones/computing devices to display? This is the response to "When Ukraine successfully reclaims the occupied territory", not only Ukraine reclaimed the occupied territory but also the rest of the world did.
Possibly. Unlike the Europe/Simferopol tzdb region, which had different time zone rules post-1970 and prior to the Russian occupation, Mariupol and Kherson were, I presume, on Kyiv time, so a time change there would require the creation of a new tzdb region Europe/Simferopol was also on Kyiv time, but as I said earlier, only russian requests are approved without any consideration to Theory and pragmatics of the tz code and data
Because that's not a change that affects time conversion. It's like the change from Asia/Calcutta to Asia/Kolkata; Kyiv is not the name change. You don't have time for Kyiv in the tz databse. You have enough requests to correct the error, but again, it is not the russian requests...
ср, 29 июн. 2022 г. в 23:46, Guy Harris <gharris@sonic.net>:
On Jun 29, 2022, at 10:17 AM, Petro Ord via tz <tz@iana.org> wrote:
Is the news about russia revoking Lithuania independence a valid notice? https://www.lrt.lt/en/news-in-english/19/1714852/russia-s-duma-mulls-revokin...
It's a notice that a member of the Duma has submitted a bill to revoke the resolution “On Recognising the Independence of the Republic of Lithuania”.
It's not yet a law, so Russia has not revoked Lithuanian independence.
And changing the time observed in Lithuania will take more than a bill being passed by the Duma and a signature of that bill by the President of Russia, it would also require a successful occupation of a NATO member by Russia.
So it's not a notice relevant to the tzdb.
When Ukraine successfully reclaims the occupied territory I assume one thing they will do is revert the local time back to Ukrainian standards United Nations General Assembly Resolution 68/262 adopted on 27 March 2014 affirmed the General Assembly's commitment to the territorial integrity of Ukraine within its internationally recognized borders and underscored the invalidity of the 2014 Crimean referendum.
What affect has the resolution had on the time to which Crimean residents set their watches and that Crimean residents expect their mobile phones/computing devices to display?
What will you do if russia decides to change time in Mariupol and Kherson? Will the answer be that theory.html says, "If boundaries between regions are fluid, such as during a war or insurrection, do not bother to create a new timezone merely because of yet another boundary change." (https://mm.icann.org/pipermail/tz/2022-May/031414.html)
Possibly. Unlike the Europe/Simferopol tzdb region, which had different time zone rules post-1970 and prior to the Russian occupation, Mariupol and Kherson were, I presume, on Kyiv time, so a time change there would require the creation of a new tzdb region.
So the question ``Why are some changes done fast while Kyiv not Kiev errors remained unseen?" is open.
Because that's not a change that affects time conversion. It's like the change from Asia/Calcutta to Asia/Kolkata; the city's name was changed in 2000 or 2001, to match the pronunciation in Bengali, and the tzdb name change occurred on 2008. That name change occurred in the tzdata2008b release, which also included a number of changes that *did* affect time conversion; it wasn't a release that *solely* changed tzdb region names.
On Jun 30, 2022, at 3:11 AM, Petro Ord <petro.ordyn@gmail.com> wrote:
It seems that "If boundaries between regions are fluid, such as during a war or insurrection, do not bother to create a new timezone merely because of yet another boundary change." does not apply to russia.
Please indicate what new time zone was created as a result of either the 2014 Russian occupation of Crimea, the breakaway movement in the Donetsk and Luhansk areas, or the 2022 Russian invasion of Ukraine. Crimea was represented by the Europe/Simferopol region; that region was *changed*, but no new timezone (time zone database region) was created. No new region was created for Donetsk and Luhansk.
What affect has the resolution had on the time to which Crimean residents set their watches and that Crimean residents expect their mobile phones/computing devices to display? This is the response to "When Ukraine successfully reclaims the occupied territory", not only Ukraine reclaimed the occupied territory but also the rest of the world did.
If "claim" here means "claim that the occupied territory belongs to Ukraine", nothing has been "reclaimed" by Ukraine - before the Russian occupation, Ukraine claimed Crimea, Donetsk, and Luhansk, and they still claim it. However, "reclaim" here means to reestablish control over the occupied territory; Ukraine has not, as far as I know, pushed the Russian occupiers out of those regions and established effective control over those regions, so I suspect that most residents of Crimea keep clocks that don't use the time zone database set to Moscow time, and would thus find it inconvenient if the time kept by devices that use the time zone database (most smartphones and some personal computers) match that setting. If that's not the case, please let us know. If that *is* the case, then that means that the reality in Crimea is that most users are keeping Moscow time, the fact that this time zone setting was imposed by the Russian government rather than by the government recognized by Ukraine and the UN as the legitimate government of Crimea notwithstanding. Note that there are a number of other cases in the time zone database where time changes imposed by occupying powers are reflected in the time zone database (World War II occupations by the Axis powers and occupation of the West Bank by Israel, for example).
Because that's not a change that affects time conversion. It's like the change from Asia/Calcutta to Asia/Kolkata; Kyiv is not the name change. You don't have time for Kyiv in the tz databse.
So are you saying that a Zone entry with the following values for STDOFF, RULES, FORMAT and, except for the last line, UNTIL (the last line doesn't have an UNTIL value, as there is no known upcoming change to the rules): 2:02:04 - LMT 1880 2:02:04 - KMT 1924 May 2 2:00 - EET 1930 Jun 21 3:00 - MSK 1941 Sep 20 1:00 C-Eur CE%sT 1943 Nov 6 3:00 Russia MSK/MSD 1990 Jul 1 2:00 2:00 1:00 EEST 1991 Sep 29 3:00 2:00 C-Eur EE%sT 1996 May 13 2:00 EU EE%sT does not correctly describe the time in Kyiv and the tzdb region in which Kyiv is the largest city (at least for 1930-06-21 and later)? If so, which lines are incorrect? Those values appear in the Zone entry for that tzdb in both the current tzdata2022a version of the database and in the current Git repository version. The one difference between the Zone entry containing those lines in the current tzdata2022a version of the database and the current Git repository version of the database is the name given to the region. The version in tzdata2022a uses, in the name for that region, the name primarily used in English for its largest city in the region at one time; the version in the Git repository uses, in the name for that region, the name now primarily used in English for the largest city in the region. So if the values shown above correctly describe the time in that region, there is an entry in the current version of the tz database for that region, and thus we *do* have time for Kyiv in the tz database, it just happens to use, as the name for that region, an out-of-date English name for its largest city. That's the same as was the case for the time zone database entry for the region in which Kolkata is the largest city - before the 2008 change, the name for that region used an old English-language name for the city that didn't reflect the city's name changing in 2000/2001, and, after that change, the name for that region used an English-language name that reflected the new name.
I do not think either Petro or Yevhen is willing to listen to the actual reasons why the pending change from "Europe/Kiev" to "Europe/Kyiv" has not yet been released, nor why the time change in Crimea in 2014 was promptly accepted and approved. They prefer to believe that these actions on the part of tz maintainers are anti-Ukraine, pro-Russia political statements. There is apparently no evidence we can provide that will change this belief. -- Doug Ewell, CC, ALB | Lakewood, CO, US | ewellic.org
If no new timezone was created, then the region was *changed* for some reason. Therefore we go back again to the fact that change was made upon the news from russia. If you really cared about how people feel or were affected by such news from russia, you would have some comments like “yes we find it useful, because previous time was inconvenient, or we live using other time, or else…”. How can you state that most users of Crimea are keeping Moscow time? Did you have any surveys? Did you have any complaints about the incorrect imezone for Simferopol? You may say that Crimea had referendum, but the referendum results appeared to be different (https://www.forbes.com/sites/paulroderickgregory/2014/05/05/putins-human-rig...). Human Rights Council report stated that only 30% of Crimea citizens voted, therefore 70% were nor keeping or living by Moscow time. And there is again a question about whom to believe: Human Rights Council report or russia report. Considering the expedited update and the fact that no real confirmation was provided to support real timezone preferences of Crimea citizens, the decision was done in favor of russia for some reason other than correct time.
about reclaim In order to reclaim, one needs to agree that territory was claimed (in other words has a right to have something), but Ukraine do not recognize Crimea's claim for sovereignty and Crimea referendum, as well it is not recognized by the mentioned resolution. There is even the Ministry of Temporarily Occupied Territories and Internally displaced persons, organized to manage Donetsk, Luhansk and Crimea regions. These territories are only occupied with rusian military forces. If by Crimea users you mean military forces, then yes, they might use and live by the timezone they have come from, but these are not the people who live in the Crimea.
If so, which lines are incorrect? There is the difference between the incorrect line and not having the line. It is the same as if I asked you to show me #3 among these numbers: 1, 2, 4, 5. You don’t have hard evidence to prove that values, you have shown, correctly describe the time in Kyiv region unless you have Kyiv region values to evaluate the presupposition. It is the same problem as with numbers: Number 3 is a unit that forms part of the system of counting and calculating Numbers 1, 2, 4, 5 are also units that form part of the system of counting and calculating. The only difference is the name of that unit. Unless you have such row as 1, 2, 3, 4, 5, it is impossible to show #3. Therefore you might have the correct values for the region; the issue is that you don’t have such a region.
чт, 30 июн. 2022 г. в 14:43, Guy Harris <gharris@sonic.net>:
On Jun 30, 2022, at 3:11 AM, Petro Ord <petro.ordyn@gmail.com> wrote:
It seems that "If boundaries between regions are fluid, such as during a war or insurrection, do not bother to create a new timezone merely because of yet another boundary change." does not apply to russia.
Please indicate what new time zone was created as a result of either the 2014 Russian occupation of Crimea, the breakaway movement in the Donetsk and Luhansk areas, or the 2022 Russian invasion of Ukraine.
Crimea was represented by the Europe/Simferopol region; that region was *changed*, but no new timezone (time zone database region) was created. No new region was created for Donetsk and Luhansk.
What affect has the resolution had on the time to which Crimean residents set their watches and that Crimean residents expect their mobile phones/computing devices to display? This is the response to "When Ukraine successfully reclaims the occupied territory", not only Ukraine reclaimed the occupied territory but also the rest of the world did.
If "claim" here means "claim that the occupied territory belongs to Ukraine", nothing has been "reclaimed" by Ukraine - before the Russian occupation, Ukraine claimed Crimea, Donetsk, and Luhansk, and they still claim it.
However, "reclaim" here means to reestablish control over the occupied territory; Ukraine has not, as far as I know, pushed the Russian occupiers out of those regions and established effective control over those regions, so I suspect that most residents of Crimea keep clocks that don't use the time zone database set to Moscow time, and would thus find it inconvenient if the time kept by devices that use the time zone database (most smartphones and some personal computers) match that setting.
If that's not the case, please let us know.
If that *is* the case, then that means that the reality in Crimea is that most users are keeping Moscow time, the fact that this time zone setting was imposed by the Russian government rather than by the government recognized by Ukraine and the UN as the legitimate government of Crimea notwithstanding.
Note that there are a number of other cases in the time zone database where time changes imposed by occupying powers are reflected in the time zone database (World War II occupations by the Axis powers and occupation of the West Bank by Israel, for example).
Because that's not a change that affects time conversion. It's like the change from Asia/Calcutta to Asia/Kolkata; Kyiv is not the name change. You don't have time for Kyiv in the tz databse.
So are you saying that a Zone entry with the following values for STDOFF, RULES, FORMAT and, except for the last line, UNTIL (the last line doesn't have an UNTIL value, as there is no known upcoming change to the rules):
2:02:04 - LMT 1880 2:02:04 - KMT 1924 May 2 2:00 - EET 1930 Jun 21 3:00 - MSK 1941 Sep 20 1:00 C-Eur CE%sT 1943 Nov 6 3:00 Russia MSK/MSD 1990 Jul 1 2:00 2:00 1:00 EEST 1991 Sep 29 3:00 2:00 C-Eur EE%sT 1996 May 13 2:00 EU EE%sT
does not correctly describe the time in Kyiv and the tzdb region in which Kyiv is the largest city (at least for 1930-06-21 and later)?
If so, which lines are incorrect?
Those values appear in the Zone entry for that tzdb in both the current tzdata2022a version of the database and in the current Git repository version.
The one difference between the Zone entry containing those lines in the current tzdata2022a version of the database and the current Git repository version of the database is the name given to the region. The version in tzdata2022a uses, in the name for that region, the name primarily used in English for its largest city in the region at one time; the version in the Git repository uses, in the name for that region, the name now primarily used in English for the largest city in the region.
So if the values shown above correctly describe the time in that region, there is an entry in the current version of the tz database for that region, and thus we *do* have time for Kyiv in the tz database, it just happens to use, as the name for that region, an out-of-date English name for its largest city.
That's the same as was the case for the time zone database entry for the region in which Kolkata is the largest city - before the 2008 change, the name for that region used an old English-language name for the city that didn't reflect the city's name changing in 2000/2001, and, after that change, the name for that region used an English-language name that reflected the new name.
You are making assertions that are demonstrably false and have been repeatedly discredited. Stop. It is rude, disrespectful, and will not get you anywhere. It is borderline trolling at this point. In my opinion, there is no need for anyone to continue responding. He is not listening to anyone, refuses to accept that decisions were not made for political reasons, and has zero justification for continuing to push for something that has never been done before for a renaming (an immediate release). I suggest everyone cease responding to this thread as a result. Jacob Pratt On Thu, Jun 30, 2022, 17:12 Petro Ord via tz <tz@iana.org> wrote:
If no new timezone was created, then the region was *changed* for some reason. Therefore we go back again to the fact that change was made upon the news from russia.
If you really cared about how people feel or were affected by such news from russia, you would have some comments like “yes we find it useful, because previous time was inconvenient, or we live using other time, or else…”.
How can you state that most users of Crimea are keeping Moscow time? Did you have any surveys? Did you have any complaints about the incorrect imezone for Simferopol?
You may say that Crimea had referendum, but the referendum results appeared to be different ( https://www.forbes.com/sites/paulroderickgregory/2014/05/05/putins-human-rig... ). Human Rights Council report stated that only 30% of Crimea citizens voted, therefore 70% were nor keeping or living by Moscow time.
And there is again a question about whom to believe: Human Rights Council report or russia report. Considering the expedited update and the fact that no real confirmation was provided to support real timezone preferences of Crimea citizens, the decision was done in favor of russia for some reason other than correct time.
about reclaim In order to reclaim, one needs to agree that territory was claimed (in other words has a right to have something), but Ukraine do not recognize Crimea's claim for sovereignty and Crimea referendum, as well it is not recognized by the mentioned resolution. There is even the Ministry of Temporarily Occupied Territories and Internally displaced persons, organized to manage Donetsk, Luhansk and Crimea regions. These territories are only occupied with rusian military forces. If by Crimea users you mean military forces, then yes, they might use and live by the timezone they have come from, but these are not the people who live in the Crimea.
If so, which lines are incorrect? There is the difference between the incorrect line and not having the line. It is the same as if I asked you to show me #3 among these numbers: 1, 2, 4, 5. You don’t have hard evidence to prove that values, you have shown, correctly describe the time in Kyiv region unless you have Kyiv region values to evaluate the presupposition. It is the same problem as with numbers: Number 3 is a unit that forms part of the system of counting and calculating Numbers 1, 2, 4, 5 are also units that form part of the system of counting and calculating. The only difference is the name of that unit. Unless you have such row as 1, 2, 3, 4, 5, it is impossible to show #3. Therefore you might have the correct values for the region; the issue is that you don’t have such a region.
чт, 30 июн. 2022 г. в 14:43, Guy Harris <gharris@sonic.net>:
On Jun 30, 2022, at 3:11 AM, Petro Ord <petro.ordyn@gmail.com> wrote:
It seems that "If boundaries between regions are fluid, such as during a war or insurrection, do not bother to create a new timezone merely because of yet another boundary change." does not apply to russia.
Please indicate what new time zone was created as a result of either the
2014 Russian occupation of Crimea, the breakaway movement in the Donetsk and Luhansk areas, or the 2022 Russian invasion of Ukraine.
Crimea was represented by the Europe/Simferopol region; that region was
*changed*, but no new timezone (time zone database region) was created. No new region was created for Donetsk and Luhansk.
What affect has the resolution had on the time to which Crimean
residents set
their watches and that Crimean residents expect their mobile phones/computing devices to display? This is the response to "When Ukraine successfully reclaims the occupied territory", not only Ukraine reclaimed the occupied territory but also the rest of the world did.
If "claim" here means "claim that the occupied territory belongs to Ukraine", nothing has been "reclaimed" by Ukraine - before the Russian occupation, Ukraine claimed Crimea, Donetsk, and Luhansk, and they still claim it.
However, "reclaim" here means to reestablish control over the occupied territory; Ukraine has not, as far as I know, pushed the Russian occupiers out of those regions and established effective control over those regions, so I suspect that most residents of Crimea keep clocks that don't use the time zone database set to Moscow time, and would thus find it inconvenient if the time kept by devices that use the time zone database (most smartphones and some personal computers) match that setting.
If that's not the case, please let us know.
If that *is* the case, then that means that the reality in Crimea is that most users are keeping Moscow time, the fact that this time zone setting was imposed by the Russian government rather than by the government recognized by Ukraine and the UN as the legitimate government of Crimea notwithstanding.
Note that there are a number of other cases in the time zone database where time changes imposed by occupying powers are reflected in the time zone database (World War II occupations by the Axis powers and occupation of the West Bank by Israel, for example).
Because that's not a change that affects time conversion. It's like the change from Asia/Calcutta to Asia/Kolkata; Kyiv is not the name change. You don't have time for Kyiv in the tz databse.
So are you saying that a Zone entry with the following values for STDOFF, RULES, FORMAT and, except for the last line, UNTIL (the last line doesn't have an UNTIL value, as there is no known upcoming change to the rules):
2:02:04 - LMT 1880 2:02:04 - KMT 1924 May 2 2:00 - EET 1930 Jun 21 3:00 - MSK 1941 Sep 20 1:00 C-Eur CE%sT 1943 Nov 6 3:00 Russia MSK/MSD 1990 Jul 1 2:00 2:00 1:00 EEST 1991 Sep 29 3:00 2:00 C-Eur EE%sT 1996 May 13 2:00 EU EE%sT
does not correctly describe the time in Kyiv and the tzdb region in which Kyiv is the largest city (at least for 1930-06-21 and later)?
If so, which lines are incorrect?
Those values appear in the Zone entry for that tzdb in both the current tzdata2022a version of the database and in the current Git repository version.
The one difference between the Zone entry containing those lines in the current tzdata2022a version of the database and the current Git repository version of the database is the name given to the region. The version in tzdata2022a uses, in the name for that region, the name primarily used in English for its largest city in the region at one time; the version in the Git repository uses, in the name for that region, the name now primarily used in English for the largest city in the region.
So if the values shown above correctly describe the time in that region, there is an entry in the current version of the tz database for that region, and thus we *do* have time for Kyiv in the tz database, it just happens to use, as the name for that region, an out-of-date English name for its largest city.
That's the same as was the case for the time zone database entry for the region in which Kolkata is the largest city - before the 2008 change, the name for that region used an old English-language name for the city that didn't reflect the city's name changing in 2000/2001, and, after that change, the name for that region used an English-language name that reflected the new name.
You are making assertions that are demonstrably false and have been repeatedly discredited. Stop. It is rude, disrespectful, and will not get you anywhere. It is borderline trolling at this point. I think you didn't even read my answers.
refuses to accept that decisions were not made for political reasons Yes, because facts say differently.
zero justification for continuing to push for something that has never been done before for a renaming (an immediate release). I'm not pushing the release. This is your assumption.
пт, 1 июл. 2022 г. в 00:19, Jacob Pratt <jacob@jhpratt.dev>:
You are making assertions that are demonstrably false and have been repeatedly discredited. Stop. It is rude, disrespectful, and will not get you anywhere. It is borderline trolling at this point.
In my opinion, there is no need for anyone to continue responding. He is not listening to anyone, refuses to accept that decisions were not made for political reasons, and has zero justification for continuing to push for something that has never been done before for a renaming (an immediate release). I suggest everyone cease responding to this thread as a result.
Jacob Pratt
On Thu, Jun 30, 2022, 17:12 Petro Ord via tz <tz@iana.org> wrote:
If no new timezone was created, then the region was *changed* for some reason. Therefore we go back again to the fact that change was made upon the news from russia.
If you really cared about how people feel or were affected by such news from russia, you would have some comments like “yes we find it useful, because previous time was inconvenient, or we live using other time, or else…”.
How can you state that most users of Crimea are keeping Moscow time? Did you have any surveys? Did you have any complaints about the incorrect imezone for Simferopol?
You may say that Crimea had referendum, but the referendum results appeared to be different (https://www.forbes.com/sites/paulroderickgregory/2014/05/05/putins-human-rig...). Human Rights Council report stated that only 30% of Crimea citizens voted, therefore 70% were nor keeping or living by Moscow time.
And there is again a question about whom to believe: Human Rights Council report or russia report. Considering the expedited update and the fact that no real confirmation was provided to support real timezone preferences of Crimea citizens, the decision was done in favor of russia for some reason other than correct time.
about reclaim In order to reclaim, one needs to agree that territory was claimed (in other words has a right to have something), but Ukraine do not recognize Crimea's claim for sovereignty and Crimea referendum, as well it is not recognized by the mentioned resolution. There is even the Ministry of Temporarily Occupied Territories and Internally displaced persons, organized to manage Donetsk, Luhansk and Crimea regions. These territories are only occupied with rusian military forces. If by Crimea users you mean military forces, then yes, they might use and live by the timezone they have come from, but these are not the people who live in the Crimea.
If so, which lines are incorrect? There is the difference between the incorrect line and not having the line. It is the same as if I asked you to show me #3 among these numbers: 1, 2, 4, 5. You don’t have hard evidence to prove that values, you have shown, correctly describe the time in Kyiv region unless you have Kyiv region values to evaluate the presupposition. It is the same problem as with numbers: Number 3 is a unit that forms part of the system of counting and calculating Numbers 1, 2, 4, 5 are also units that form part of the system of counting and calculating. The only difference is the name of that unit. Unless you have such row as 1, 2, 3, 4, 5, it is impossible to show #3. Therefore you might have the correct values for the region; the issue is that you don’t have such a region.
чт, 30 июн. 2022 г. в 14:43, Guy Harris <gharris@sonic.net>:
On Jun 30, 2022, at 3:11 AM, Petro Ord <petro.ordyn@gmail.com> wrote:
It seems that "If boundaries between regions are fluid, such as during a war or insurrection, do not bother to create a new timezone merely because of yet another boundary change." does not apply to russia.
Please indicate what new time zone was created as a result of either the 2014 Russian occupation of Crimea, the breakaway movement in the Donetsk and Luhansk areas, or the 2022 Russian invasion of Ukraine.
Crimea was represented by the Europe/Simferopol region; that region was *changed*, but no new timezone (time zone database region) was created. No new region was created for Donetsk and Luhansk.
What affect has the resolution had on the time to which Crimean residents set their watches and that Crimean residents expect their mobile phones/computing devices to display? This is the response to "When Ukraine successfully reclaims the occupied territory", not only Ukraine reclaimed the occupied territory but also the rest of the world did.
If "claim" here means "claim that the occupied territory belongs to Ukraine", nothing has been "reclaimed" by Ukraine - before the Russian occupation, Ukraine claimed Crimea, Donetsk, and Luhansk, and they still claim it.
However, "reclaim" here means to reestablish control over the occupied territory; Ukraine has not, as far as I know, pushed the Russian occupiers out of those regions and established effective control over those regions, so I suspect that most residents of Crimea keep clocks that don't use the time zone database set to Moscow time, and would thus find it inconvenient if the time kept by devices that use the time zone database (most smartphones and some personal computers) match that setting.
If that's not the case, please let us know.
If that *is* the case, then that means that the reality in Crimea is that most users are keeping Moscow time, the fact that this time zone setting was imposed by the Russian government rather than by the government recognized by Ukraine and the UN as the legitimate government of Crimea notwithstanding.
Note that there are a number of other cases in the time zone database where time changes imposed by occupying powers are reflected in the time zone database (World War II occupations by the Axis powers and occupation of the West Bank by Israel, for example).
Because that's not a change that affects time conversion. It's like the change from Asia/Calcutta to Asia/Kolkata; Kyiv is not the name change. You don't have time for Kyiv in the tz databse.
So are you saying that a Zone entry with the following values for STDOFF, RULES, FORMAT and, except for the last line, UNTIL (the last line doesn't have an UNTIL value, as there is no known upcoming change to the rules):
2:02:04 - LMT 1880 2:02:04 - KMT 1924 May 2 2:00 - EET 1930 Jun 21 3:00 - MSK 1941 Sep 20 1:00 C-Eur CE%sT 1943 Nov 6 3:00 Russia MSK/MSD 1990 Jul 1 2:00 2:00 1:00 EEST 1991 Sep 29 3:00 2:00 C-Eur EE%sT 1996 May 13 2:00 EU EE%sT
does not correctly describe the time in Kyiv and the tzdb region in which Kyiv is the largest city (at least for 1930-06-21 and later)?
If so, which lines are incorrect?
Those values appear in the Zone entry for that tzdb in both the current tzdata2022a version of the database and in the current Git repository version.
The one difference between the Zone entry containing those lines in the current tzdata2022a version of the database and the current Git repository version of the database is the name given to the region. The version in tzdata2022a uses, in the name for that region, the name primarily used in English for its largest city in the region at one time; the version in the Git repository uses, in the name for that region, the name now primarily used in English for the largest city in the region.
So if the values shown above correctly describe the time in that region, there is an entry in the current version of the tz database for that region, and thus we *do* have time for Kyiv in the tz database, it just happens to use, as the name for that region, an out-of-date English name for its largest city.
That's the same as was the case for the time zone database entry for the region in which Kolkata is the largest city - before the 2008 change, the name for that region used an old English-language name for the city that didn't reflect the city's name changing in 2000/2001, and, after that change, the name for that region used an English-language name that reflected the new name.
On 29/06/2022 18:17, Petro Ord wrote:
Corrections for times in the past are also welcome (e.g. for last winter), but note that "the wrong time" means that the local time indicated for the zone differs from the actual time that people in that region lived their lives by, e.g. transport departure and arrival times, store opening and closing times, work day start and end times, TV and radio programme start and end times, etc.
Fascinating how requirements differ for countries. For Crimea update a notice was enough
Alexander Krivenyshev wrote: http://voiceofrussia.com/news/2014_03_17/Crimea-to-switch-to-Moscow-Time-as- of-March-30-8334/ Thanks for the heads-up. That notice says that they'll switch to Moscow Time at 2pm, which means they'd advance their clocks by an hour once at 01:00 UTC (03:00 local time) and once again at 14:00 local time.
No transport departure and arrival times, no store opening and closing times, no work day start and end times, no TV and radio programme start and end times, etc., just a notice will do.
At that point it seemed most probable that the clocks would in fact change on March 30 (the Russian/pro-Russian forces had effectively been in control of the region for nearly a month at that point with no sign of change), so Paul released version 2014b on March 24 since it affected local time changes in the very near future. -- -=( Ian Abbott <abbotti@mev.co.uk> || MEV Ltd. is a company )=- -=( registered in England & Wales. Regd. number: 02862268. )=- -=( Regd. addr.: S11 & 12 Building 67, Europa Business Park, )=- -=( Bird Hall Lane, STOCKPORT, SK3 0XA, UK. || www.mev.co.uk )=-
# From Alexander Krivenyshev (2014-03-17): # time change at 2:00 (2am) on March 30, 2014 # https://vz.ru/news/2014/3/17/677464.html # From Paul Eggert (2014-03-30): # Simferopol and Sevastopol reportedly changed their central town clocks Here is the news about russia initiative to revoke independence of Lithuania (https://www.lrt.lt/en/news-in-english/19/1714852/russia-s-duma-mulls-revokin...) If tomorrow russia have the news abuot changing time in Lithuania, will you update the uncomping repo to include this change?! And from the Theory file: | Most timezones correspond to a notable location and the database | records all known clock transitions for that location; some | timezones correspond instead to a fixed UTC offset.
Nowhere in the Theory file does it say, “make a change to a database key because we want to take sides in a war.”
The Theory does not take sides, it is the person who makes the change does. Please do not consider it any personal implication, but the number of previously neglected requests about Ukraine only supports the intolerance. ср, 29 июн. 2022 г. в 12:32, Ian Abbott <abbotti@mev.co.uk>:
On 29/06/2022 09:55, Petro Ord via tz wrote:
The Crimea time zone was rather quickly updated and added to the upcoming release in 2014, especially considering that Crimea is internationally recognized as being part of Ukraine. I don't think it was guided by the Theory file.
Time zones are added/updated for pragmatic reasons to reflect the history of actual wall clock time in a particular region, not for idealogical reasons. See these comments in the "europe" file for Europe/Simferopol:
# From Alexander Krivenyshev (2014-03-17): # time change at 2:00 (2am) on March 30, 2014 # https://vz.ru/news/2014/3/17/677464.html # From Paul Eggert (2014-03-30): # Simferopol and Sevastopol reportedly changed their central town clocks # late the previous day, but this appears to have been ceremonial # and the discrepancies are small enough to not worry about.
And from the Theory file:
| Most timezones correspond to a notable location and the database | records all known clock transitions for that location; some | timezones correspond instead to a fixed UTC offset.
-- -=( Ian Abbott <abbotti@mev.co.uk> || MEV Ltd. is a company )=- -=( registered in England & Wales. Regd. number: 02862268. )=- -=( Regd. addr.: S11 & 12 Building 67, Europa Business Park, )=- -=( Bird Hall Lane, STOCKPORT, SK3 0XA, UK. || www.mev.co.uk )=-
On 2022-06-28 20:54:13 (+0800), Martin Burnicki via tz wrote:
even though usually a new version of the DB is only released if some TZ rule was changed, it should not be too hard to simply release a new version now
I strongly disagree with this view. While the effort required from the tz coordinator to tag a release may be minimal, this is not the case for the many downstream maintainers. Every update presents a risk. Bear in mind that tzdb updates end up being pushed to hundreds of millions of end-user devices, if not more. Downstream maintainers are cranky enough as-is, following the churn in 2021 (which still has not been completely resolved). If we start tagging tzdb releases without actual tz changes, downstream maintainers will be even more likely to diverge from the closely tracking tzdb. This is ultimately bad news for end users. For the avoidance of doubt: I completely agree that renaming Europe/Kiev to Europe/Kyiv was the correct thing to do. My objection is to tagging tzdb releases with only commentary changes and no data changes. Having said that: we should try to do even better to clarify the scope of the tzdb project to casual readers. It is clear that most recent first-time contributors to this mailing list are not familiar with the theory and pragmatism of the tzdb. I do not have a solution to this problem. Philip -- Philip Paeps Senior Reality Engineer Alternative Enterprises
On Wed, 29 Jun 2022 at 17:51, Philip Paeps via tz <tz@iana.org> wrote:
On 2022-06-28 20:54:13 (+0800), Martin Burnicki via tz wrote:
even though usually a new version of the DB is only released if some TZ rule was changed, it should not be too hard to simply release a new version now
I strongly disagree with this view.
While the effort required from the tz coordinator to tag a release may be minimal, this is not the case for the many downstream maintainers. Every update presents a risk. Bear in mind that tzdb updates end up being pushed to hundreds of millions of end-user devices, if not more.
Downstream maintainers are cranky enough as-is, following the churn in 2021 (which still has not been completely resolved). If we start tagging tzdb releases without actual tz changes, downstream maintainers will be even more likely to diverge from the closely tracking tzdb. This is ultimately bad news for end users.
For the avoidance of doubt: I completely agree that renaming Europe/Kiev to Europe/Kyiv was the correct thing to do. My objection is to tagging tzdb releases with only commentary changes and no data changes.
Counterpoint, as a downstream maintainer I would appreciate prompt releases for popular requests such as the renaming of Europe/Kiev. Fielding requests and redirecting them to IANA has already taken more time and mindshare than me popping out a new release with updated data. In hindsight I should have added an override and made a release months ago. If anything, infrequent releases are more of a problem for me (of course I can't speak for other downstreams). The longer between releases, the more likely it is that my release machinery has atrophied, the more accumulated bugs need to be fixed, and under higher time pressure as the release is more likely to have some time critical change included. While I don't think every change prompting a release would be good, I do think an expected release cadence of one release every 3-4 months would be an improvement, along with the occasional unexpected release containing time critical changes. -- Stuart Bishop <stuart@stuartbishop.net> http://www.stuartbishop.net/
[ disclaimer: I too am just a downstream maintainer ] Stuart Bishop via tz <tz@iana.org> writes:
If anything, infrequent releases are more of a problem for me (of course I can't speak for other downstreams). The longer between releases, the more likely it is that my release machinery has atrophied, the more accumulated bugs need to be fixed, and under higher time pressure as the release is more likely to have some time critical change included. While I don't think every change prompting a release would be good, I do think an expected release cadence of one release every 3-4 months would be an improvement, along with the occasional unexpected release containing time critical changes.
You make some good points, but really that doesn't seem very much different from the historical state of affairs. In my recollection, there is pretty much always at least one release every spring and every fall, when some-government-or-other decides they need to change their DST rules with minimal notice. So in practice there's a six-months-or-less release cadence, and I doubt that making it three or four months would change anything noticeable. The current situation with Kyiv/Kiev is a bit unfortunate in that the decision to change that name was made just after the March silly season, so that it will have the maximum probable wait time before hitting the streets. Still, I agree with the position that making a release just for that would be a bad precedent. What I think might be worth thinking about is decoupling the tzcode and tzdata release calendars. The forcing functions for those two things are *completely* different, and so are the considerations for downstream maintainers. IIUC the reason for bundling them is to cover the case where a new tzdata release requires new tzcode. But in practice, there's always been very strong concern for backwards compatibility, so that tzdata releases are expected to work with older tzcode; and I think that has to be so because a maintainer of a tzdata distribution can't really guarantee that no older code will be reading that copy of the database. So I'd be in favor of a more formal separation. regards, tom lane
On 6/30/22 22:13, Tom Lane via tz wrote:
IIUC the reason for bundling them is to cover the case where a new tzdata release requires new tzcode.
Yes, in the old days it was never entirely clear what the relationship was between tzdata1997e and tzcode1997e as the two release numbers came from separate lines of development. Now, it's obvious. Also, using the same version number simplifies tarball generation. Some of this was discussed here: https://mm.icann.org/pipermail/tz/2012-September/thread.html#18258
On Fri, 1 Jul 2022 at 00:00, Philip Paeps via tz <tz@iana.org> wrote:
As Tom points out, we actually have a fairly predictable schedule today: bursts of releases around the silly seasons in March and October and one or two releases at other times. I'm not too worried about our release machinery atrophying.
And, even if we go an entire "season" without zone changes, leap second data expires twice-yearly as well whether there's a leap-second or not: Even if there are no zone changes in the Mar/Apr season, we would still need a release around May to incorporate the Jan announcement regarding a possible Jun leap-second. Even if there are no zone changes in the Sep/Oct season, we would still need a release around Nov to incorporate the Jul announcement regarding a possible Dec leap-second. So the point about avoiding atrophy is well-taken, but I don't foresee us dipping below a minimum of two releases a year. And because of the above, I also don't see the need to impose any further arbitrary schedule on releases either.
Unfortunately, the nature of the data we record means we'll always have to make releases on short notice.
Yup, no avoiding that. -- Tim Parenti On Fri, 1 Jul 2022 at 00:22, Paul Eggert via tz <tz@iana.org> wrote:
On 6/30/22 22:13, Tom Lane via tz wrote:
IIUC the reason for bundling them is to cover the case where a new tzdata release requires new tzcode.
Yes, in the old days it was never entirely clear what the relationship was between tzdata1997e and tzcode1997e as the two release numbers came from separate lines of development. Now, it's obvious. Also, using the same version number simplifies tarball generation.
Some of this was discussed here:
https://mm.icann.org/pipermail/tz/2012-September/thread.html#18258
On 01/07/2022 04:13, Tom Lane via tz wrote:
[...] In my recollection, there is pretty much always at least one release every spring and every fall, when some-government-or-other decides they need to change their DST rules with minimal notice. So in practice there's a six-months-or-less release cadence, and I doubt that making it three or four months would change anything noticeable.
If we somehow get through this year's late silly season with no urgent releases, the current release will be out-of-date on 2023-March-21 (due to DST changes in Iran) so we'd need a release a few months before then to allow plenty of lead time for downstream maintainers and consumers. -- -=( Ian Abbott <abbotti@mev.co.uk> || MEV Ltd. is a company )=- -=( registered in England & Wales. Regd. number: 02862268. )=- -=( Regd. addr.: S11 & 12 Building 67, Europa Business Park, )=- -=( Bird Hall Lane, STOCKPORT, SK3 0XA, UK. || www.mev.co.uk )=-
If we somehow get through this year's late silly season with no urgent releases, the current release will be out-of-date on 2023-March-21 (due to DST changes in Iran) so we'd need a release a few months before then to allow plenty of lead time for downstream maintainers and consumers.
So the fact that Ukraine DST ends in October 2022 does even bother you. пт, 1 июл. 2022 г. в 21:11, Ian Abbott via tz <tz@iana.org>:
On 01/07/2022 04:13, Tom Lane via tz wrote:
[...] In my recollection, there is pretty much always at least one release every spring and every fall, when some-government-or-other decides they need to change their DST rules with minimal notice. So in practice there's a six-months-or-less release cadence, and I doubt that making it three or four months would change anything noticeable.
If we somehow get through this year's late silly season with no urgent releases, the current release will be out-of-date on 2023-March-21 (due to DST changes in Iran) so we'd need a release a few months before then to allow plenty of lead time for downstream maintainers and consumers.
-- -=( Ian Abbott <abbotti@mev.co.uk> || MEV Ltd. is a company )=- -=( registered in England & Wales. Regd. number: 02862268. )=- -=( Regd. addr.: S11 & 12 Building 67, Europa Business Park, )=- -=( Bird Hall Lane, STOCKPORT, SK3 0XA, UK. || www.mev.co.uk )=-
If we somehow get through this year's late silly season with no urgent releases, the current release will be out-of-date on 2023-March-21 (due to DST changes in Iran) so we'd need a release a few months before then to allow plenty of lead time for downstream maintainers and consumers.
*forget to add not* So the fact that Ukraine DST ends on October 2022 does not even bother you. пт, 1 июл. 2022 г. в 22:14, Petro Ord <petro.ordyn@gmail.com>:
If we somehow get through this year's late silly season with no urgent releases, the current release will be out-of-date on 2023-March-21 (due to DST changes in Iran) so we'd need a release a few months before then to allow plenty of lead time for downstream maintainers and consumers.
So the fact that Ukraine DST ends in October 2022 does even bother you.
пт, 1 июл. 2022 г. в 21:11, Ian Abbott via tz <tz@iana.org>:
On 01/07/2022 04:13, Tom Lane via tz wrote:
[...] In my recollection, there is pretty much always at least one release every spring and every fall, when some-government-or-other decides they need to change their DST rules with minimal notice. So in practice there's a six-months-or-less release cadence, and I doubt that making it three or four months would change anything noticeable.
If we somehow get through this year's late silly season with no urgent releases, the current release will be out-of-date on 2023-March-21 (due to DST changes in Iran) so we'd need a release a few months before then to allow plenty of lead time for downstream maintainers and consumers.
-- -=( Ian Abbott <abbotti@mev.co.uk> || MEV Ltd. is a company )=- -=( registered in England & Wales. Regd. number: 02862268. )=- -=( Regd. addr.: S11 & 12 Building 67, Europa Business Park, )=- -=( Bird Hall Lane, STOCKPORT, SK3 0XA, UK. || www.mev.co.uk )=-
On 01/07/2022 20:15, Petro Ord wrote:
If we somehow get through this year's late silly season with no urgent releases, the current release will be out-of-date on 2023-March-21 (due to DST changes in Iran) so we'd need a release a few months before then to allow plenty of lead time for downstream maintainers and consumers.
*forget to add not* So the fact that Ukraine DST ends on October 2022 does not even bother you.
[Disclaimer - I am just an interested observer, not a maintainer.] Do you mean there are future timezone changes to Europe/Kyiv, Europe/Simferopol, Europe/Uzhgorod, and/or Europe/Zaporozhye that the database does not currently handle? If no, then no it doesn't bother me. If yes, then please send links to the official announcements in a new thread. -- -=( Ian Abbott <abbotti@mev.co.uk> || MEV Ltd. is a company )=- -=( registered in England & Wales. Regd. number: 02862268. )=- -=( Regd. addr.: S11 & 12 Building 67, Europa Business Park, )=- -=( Bird Hall Lane, STOCKPORT, SK3 0XA, UK. || www.mev.co.uk )=-
Do you mean there are future timezone changes to Europe/Kyiv If it had been in the tz database I would type it as such.
please send links to the official announcements in a new thread Thank you for the clarification
пт, 1 июл. 2022 г. в 23:00, Ian Abbott <abbotti@mev.co.uk>:
On 01/07/2022 20:15, Petro Ord wrote:
If we somehow get through this year's late silly season with no urgent releases, the current release will be out-of-date on 2023-March-21 (due to DST changes in Iran) so we'd need a release a few months before then to allow plenty of lead time for downstream maintainers and consumers.
*forget to add not* So the fact that Ukraine DST ends on October 2022 does not even bother you.
[Disclaimer - I am just an interested observer, not a maintainer.]
Do you mean there are future timezone changes to Europe/Kyiv, Europe/Simferopol, Europe/Uzhgorod, and/or Europe/Zaporozhye that the database does not currently handle? If no, then no it doesn't bother me. If yes, then please send links to the official announcements in a new thread.
-- -=( Ian Abbott <abbotti@mev.co.uk> || MEV Ltd. is a company )=- -=( registered in England & Wales. Regd. number: 02862268. )=- -=( Regd. addr.: S11 & 12 Building 67, Europa Business Park, )=- -=( Bird Hall Lane, STOCKPORT, SK3 0XA, UK. || www.mev.co.uk )=-
On 01/07/2022 21:16, Petro Ord wrote:
Do you mean there are future timezone changes to Europe/Kyiv If it had been in the tz database I would type it as such.
Obviously, future changes would be applied on top of existing changes in the development version. -- -=( Ian Abbott <abbotti@mev.co.uk> || MEV Ltd. is a company )=- -=( registered in England & Wales. Regd. number: 02862268. )=- -=( Regd. addr.: S11 & 12 Building 67, Europa Business Park, )=- -=( Bird Hall Lane, STOCKPORT, SK3 0XA, UK. || www.mev.co.uk )=-
Obviously, future changes would be applied on top of existing changes in the development version. Unless rusia issues some other nonsense news like it was in 2014. I assume there were some rules for Ukraine but since russia had decided otherwise, tz database coordinators made changes in favor of russia, despite the fact that most residents of Crimea didn't use the time zone database set to Moscow time, didn't open stores as per Moscow time etc. KyivNotKiev error was mentioned many times for several years, but it is not the russian news, so that error was not worth considering. There was a chance to correct the error in spring this year, but as per russian news Kyiv should have been captured in 2 days, so, again, there was no need to consider the error. Therefore, prompt change in Crimea in 2014 and persistent KyivNotKiev error are done for political reason in favor of terrorist country - russia
сб, 2 июл. 2022 г. в 12:10, Ian Abbott <abbotti@mev.co.uk>:
On 01/07/2022 21:16, Petro Ord wrote:
Do you mean there are future timezone changes to Europe/Kyiv If it had been in the tz database I would type it as such.
Obviously, future changes would be applied on top of existing changes in the development version.
-- -=( Ian Abbott <abbotti@mev.co.uk> || MEV Ltd. is a company )=- -=( registered in England & Wales. Regd. number: 02862268. )=- -=( Regd. addr.: S11 & 12 Building 67, Europa Business Park, )=- -=( Bird Hall Lane, STOCKPORT, SK3 0XA, UK. || www.mev.co.uk )=-
Can we block him from the list? Personal attacks are repulsive and should not be allowed, let alone repeatedly. Jacob Pratt On Sat, Jul 2, 2022, 05:47 Petro Ord via tz <tz@iana.org> wrote:
Obviously, future changes would be applied on top of existing changes in the development version. Unless rusia issues some other nonsense news like it was in 2014. I assume there were some rules for Ukraine but since russia had decided otherwise, tz database coordinators made changes in favor of russia, despite the fact that most residents of Crimea didn't use the time zone database set to Moscow time, didn't open stores as per Moscow time etc. KyivNotKiev error was mentioned many times for several years, but it is not the russian news, so that error was not worth considering. There was a chance to correct the error in spring this year, but as per russian news Kyiv should have been captured in 2 days, so, again, there was no need to consider the error. Therefore, prompt change in Crimea in 2014 and persistent KyivNotKiev error are done for political reason in favor of terrorist country - russia
сб, 2 июл. 2022 г. в 12:10, Ian Abbott <abbotti@mev.co.uk>:
On 01/07/2022 21:16, Petro Ord wrote:
Do you mean there are future timezone changes to Europe/Kyiv If it had been in the tz database I would type it as such.
Obviously, future changes would be applied on top of existing changes in the development version.
-- -=( Ian Abbott <abbotti@mev.co.uk> || MEV Ltd. is a company )=- -=( registered in England & Wales. Regd. number: 02862268. )=- -=( Regd. addr.: S11 & 12 Building 67, Europa Business Park, )=- -=( Bird Hall Lane, STOCKPORT, SK3 0XA, UK. || www.mev.co.uk )=-
Of course you can block me as well as delete all requests to correct KyivNotKiev errors. Because when tz coordinators say they want to support real timezone preferences of citizens, I think, they prioritize rusian citizens’ preferences.
I forgot that, and added to the list. I should have just replied to you privately. This reply from Paul Eggert means that he has tons of such requests but does not care about the inconvenience of users. I don’t know for all users, but, for sure, not for Ukrainians, unlike rusians, whose requests are completed within few days.
сб, 2 июл. 2022 г. в 17:26, Jacob Pratt via tz <tz@iana.org>:
Can we block him from the list? Personal attacks are repulsive and should not be allowed, let alone repeatedly.
Jacob Pratt
On Sat, Jul 2, 2022, 05:47 Petro Ord via tz <tz@iana.org> wrote:
Obviously, future changes would be applied on top of existing changes in the development version. Unless rusia issues some other nonsense news like it was in 2014. I assume there were some rules for Ukraine but since russia had decided otherwise, tz database coordinators made changes in favor of russia, despite the fact that most residents of Crimea didn't use the time zone database set to Moscow time, didn't open stores as per Moscow time etc. KyivNotKiev error was mentioned many times for several years, but it is not the russian news, so that error was not worth considering. There was a chance to correct the error in spring this year, but as per russian news Kyiv should have been captured in 2 days, so, again, there was no need to consider the error. Therefore, prompt change in Crimea in 2014 and persistent KyivNotKiev error are done for political reason in favor of terrorist country - russia
сб, 2 июл. 2022 г. в 12:10, Ian Abbott <abbotti@mev.co.uk>:
On 01/07/2022 21:16, Petro Ord wrote:
Do you mean there are future timezone changes to Europe/Kyiv If it had been in the tz database I would type it as such.
Obviously, future changes would be applied on top of existing changes in the development version.
-- -=( Ian Abbott <abbotti@mev.co.uk> || MEV Ltd. is a company )=- -=( registered in England & Wales. Regd. number: 02862268. )=- -=( Regd. addr.: S11 & 12 Building 67, Europa Business Park, )=- -=( Bird Hall Lane, STOCKPORT, SK3 0XA, UK. || www.mev.co.uk )=-
On Jul 1, 2022, at 12:14 PM, Petro Ord via tz <tz@iana.org> wrote:
If we somehow get through this year's late silly season with no urgent releases, the current release will be out-of-date on 2023-March-21 (due to DST changes in Iran) so we'd need a release a few months before then to allow plenty of lead time for downstream maintainers and consumers.
So the fact that Ukraine DST ends in October 2022 does even bother you.
The time zone database currently has the region for Ukraine following EU rules, which specify that DST ends in October. Has there been an announcement from Ukraine that they will be going on permanent standard time ending in 2023?
the current release will be out-of-date on 2023-March-21 (due to DST changes in Iran) I'm trying to figure it out why it will be out-of-date only on 21 March 2023
пт, 1 июл. 2022 г. в 23:11, Guy Harris via tz <tz@iana.org>:
On Jul 1, 2022, at 12:14 PM, Petro Ord via tz <tz@iana.org> wrote:
If we somehow get through this year's late silly season with no urgent releases, the current release will be out-of-date on 2023-March-21 (due to DST changes in Iran) so we'd need a release a few months before then to allow plenty of lead time for downstream maintainers and consumers.
So the fact that Ukraine DST ends in October 2022 does even bother you.
The time zone database currently has the region for Ukraine following EU rules, which specify that DST ends in October.
Has there been an announcement from Ukraine that they will be going on permanent standard time ending in 2023?
On 2022-07-01 23:21:32+0300, Petro Ord via tz <tz@iana.org> wrote:
the current release will be out-of-date on 2023-March-21 (due to DST changes in Iran) I'm trying to figure it out why it will be out-of-date only on 21 March 2023
It's not necessary to publish tzdb for every other years since the rules are predictable. Kyiv/Kiev follows E-Eur rules, and it seems like nothing is going to change in a foreseeable future. For Iran, it's another story. Current asia file has: Rule Iran 2021 2023 - Mar 21 24:00 1:00 Rule Iran 2021 2023 - Sep 21 24:00 0 - IOW, Iran normally observe summer time, and if the rule wasn't changed, they will observe DST in 2023-Mar-21 (their 1 Farvardin). However, Iran abolishes DST from 2023. Thus, there's no clock change in 2023. If we don't publish new tzdata by then, the tzdb is obsolete.
пт, 1 июл. 2022 г. в 23:11, Guy Harris via tz <tz@iana.org>:
On Jul 1, 2022, at 12:14 PM, Petro Ord via tz <tz@iana.org> wrote:
If we somehow get through this year's late silly season with no urgent releases, the current release will be out-of-date on 2023-March-21 (due to DST changes in Iran) so we'd need a release a few months before then to allow plenty of lead time for downstream maintainers and consumers.
So the fact that Ukraine DST ends in October 2022 does even bother you.
The time zone database currently has the region for Ukraine following EU rules, which specify that DST ends in October.
Has there been an announcement from Ukraine that they will be going on permanent standard time ending in 2023?
-- Danh
However, Iran abolishes DST from 2023. Thus, there's no clock change in 2023. If we don't publish new tzdata by then, the tzdb is obsolete. This change needs to be also approved by the Guardian Council.
сб, 2 июл. 2022 г. в 03:37, Đoàn Trần Công Danh <congdanhqx@gmail.com>:
On 2022-07-01 23:21:32+0300, Petro Ord via tz <tz@iana.org> wrote:
the current release will be out-of-date on 2023-March-21 (due to DST changes in Iran) I'm trying to figure it out why it will be out-of-date only on 21 March 2023
It's not necessary to publish tzdb for every other years since the rules are predictable.
Kyiv/Kiev follows E-Eur rules, and it seems like nothing is going to change in a foreseeable future.
For Iran, it's another story.
Current asia file has:
Rule Iran 2021 2023 - Mar 21 24:00 1:00 Rule Iran 2021 2023 - Sep 21 24:00 0 -
IOW, Iran normally observe summer time, and if the rule wasn't changed, they will observe DST in 2023-Mar-21 (their 1 Farvardin).
However, Iran abolishes DST from 2023. Thus, there's no clock change in 2023. If we don't publish new tzdata by then, the tzdb is obsolete.
пт, 1 июл. 2022 г. в 23:11, Guy Harris via tz <tz@iana.org>:
On Jul 1, 2022, at 12:14 PM, Petro Ord via tz <tz@iana.org> wrote:
If we somehow get through this year's late silly season with no urgent releases, the current release will be out-of-date on 2023-March-21 (due to DST changes in Iran) so we'd need a release a few months before then to allow plenty of lead time for downstream maintainers and consumers.
So the fact that Ukraine DST ends in October 2022 does even bother you.
The time zone database currently has the region for Ukraine following EU rules, which specify that DST ends in October.
Has there been an announcement from Ukraine that they will be going on permanent standard time ending in 2023?
-- Danh
On 02/07/2022 10:18, Petro Ord via tz wrote:
However, Iran abolishes DST from 2023. Thus, there's no clock change in 2023. If we don't publish new tzdata by then, the tzdb is obsolete. This change needs to be also approved by the Guardian Council.
As indeed it was. -- -=( Ian Abbott <abbotti@mev.co.uk> || MEV Ltd. is a company )=- -=( registered in England & Wales. Regd. number: 02862268. )=- -=( Regd. addr.: S11 & 12 Building 67, Europa Business Park, )=- -=( Bird Hall Lane, STOCKPORT, SK3 0XA, UK. || www.mev.co.uk )=-
Has there been an announcement from Ukraine that they will be going on permanent standard time ending in 2023? The Government of Ukraine discusses the possibility to use permanent standard time each year, but such a decision has not been approved yet.
пт, 1 июл. 2022 г. в 23:11, Guy Harris via tz <tz@iana.org>:
On Jul 1, 2022, at 12:14 PM, Petro Ord via tz <tz@iana.org> wrote:
If we somehow get through this year's late silly season with no urgent releases, the current release will be out-of-date on 2023-March-21 (due to DST changes in Iran) so we'd need a release a few months before then to allow plenty of lead time for downstream maintainers and consumers.
So the fact that Ukraine DST ends in October 2022 does even bother you.
The time zone database currently has the region for Ukraine following EU rules, which specify that DST ends in October.
Has there been an announcement from Ukraine that they will be going on permanent standard time ending in 2023?
On Jul 1, 2022, at 4:24 PM, Petro Ord via tz <tz@iana.org> wrote:
Has there been an announcement from Ukraine that they will be going on permanent standard time ending in 2023? The Government of Ukraine discusses the possibility to use permanent standard time each year, but such a decision has not been approved yet.
There you go. Why don't you lobby there instead of here and convince them to change? This way you'll: - get your name change - get rid of the stupid Daylight Savings - conserve disk space for everyone in the list Best, christos
On 01/07/2022 21:24, Petro Ord via tz wrote:
Has there been an announcement from Ukraine that they will be going on permanent standard time ending in 2023? The Government of Ukraine discusses the possibility to use permanent standard time each year, but such a decision has not been approved yet.
Even if they don't, it may be imposed by the EU if Ukraine becomes a member thereof. The EU has already resolved to abolish DST changes in the member states, with each state getting to choose whether to stay on winter or summer time permanently. It was supposed to have been implemented by now, but keeps getting postponed. If Ukraine became a member state and eventually chose summer time as their standard time then Europe/Kyiv and Europe/Simferopol would show the same time all year round! I don't know if the UK would follow along with abolishing DST changes. They currently follow EU DST rules too, but are no longer part of the EU (sadly). -- -=( Ian Abbott <abbotti@mev.co.uk> || MEV Ltd. is a company )=- -=( registered in England & Wales. Regd. number: 02862268. )=- -=( Regd. addr.: S11 & 12 Building 67, Europa Business Park, )=- -=( Bird Hall Lane, STOCKPORT, SK3 0XA, UK. || www.mev.co.uk )=-
On 2022-07-01 10:45:00 (+0800), Stuart Bishop via tz wrote:
On Wed, 29 Jun 2022 at 17:51, Philip Paeps via tz <tz@iana.org> wrote:
On 2022-06-28 20:54:13 (+0800), Martin Burnicki via tz wrote:
even though usually a new version of the DB is only released if some TZ rule was changed, it should not be too hard to simply release a new version now
I strongly disagree with this view.
While the effort required from the tz coordinator to tag a release may be minimal, this is not the case for the many downstream maintainers. Every update presents a risk. Bear in mind that tzdb updates end up being pushed to hundreds of millions of end-user devices, if not more.
Downstream maintainers are cranky enough as-is, following the churn in 2021 (which still has not been completely resolved). If we start tagging tzdb releases without actual tz changes, downstream maintainers will be even more likely to diverge from the closely tracking tzdb. This is ultimately bad news for end users.
For the avoidance of doubt: I completely agree that renaming Europe/Kiev to Europe/Kyiv was the correct thing to do. My objection is to tagging tzdb releases with only commentary changes and no data changes.
Counterpoint, as a downstream maintainer I would appreciate prompt releases for popular requests such as the renaming of Europe/Kiev. Fielding requests and redirecting them to IANA has already taken more time and mindshare than me popping out a new release with updated data. In hindsight I should have added an override and made a release months ago.
All downstream maintainers have been in this boat. But we're a couple of dozen people at most. We have to weigh our efforts fielding email against the risk of updating hundreds of millions of end-user devices. Every update, no matter how trivial, is risky at that scale. Releases without tz changes would do much more harm than good.
If anything, infrequent releases are more of a problem for me (of course I can't speak for other downstreams). The longer between releases, the more likely it is that my release machinery has atrophied, the more accumulated bugs need to be fixed, and under higher time pressure as the release is more likely to have some time critical change included. While I don't think every change prompting a release would be good, I do think an expected release cadence of one release every 3-4 months would be an improvement, along with the occasional unexpected release containing time critical changes.
This is a good suggestion but I don't it's practical. Time zone changes tend to happen in bursts around March and October. If we scheduled releases at the beginning of January, April, July, and October, we'd invariably end up doing at least one additional release in April and October. Shifting the scheduled release to the end of the month, we'd end up doing at least one additional release earlier in the same months. And more often than not, the January and July releases would be devoid of tz changes. As Tom points out, we actually have a fairly predictable schedule today: bursts of releases around the silly seasons in March and October and one or two releases at other times. I'm not too worried about our release machinery atrophying. Unfortunately, the nature of the data we record means we'll always have to make releases on short notice. Considering the end-user impact of every release, making releases with tz changes, only when necessary, is a better compromise than making releases on a schedule, but without tz changes, in addition to releases with tz changes, when necessary. Philip -- Philip Paeps Senior Reality Engineer Alternative Enterprises
Stuart Bishop via tz wrote:
On Wed, 29 Jun 2022 at 17:51, Philip Paeps via tz <tz@iana.org <mailto:tz@iana.org>> wrote:
On 2022-06-28 20:54:13 (+0800), Martin Burnicki via tz wrote: > even though usually a new version of the DB is only released if some > TZ rule was changed, it should not be too hard to simply release a new > version now
I strongly disagree with this view.
While the effort required from the tz coordinator to tag a release may be minimal, this is not the case for the many downstream maintainers. Every update presents a risk. Bear in mind that tzdb updates end up being pushed to hundreds of millions of end-user devices, if not more.
Downstream maintainers are cranky enough as-is, following the churn in 2021 (which still has not been completely resolved). If we start tagging tzdb releases without actual tz changes, downstream maintainers will be even more likely to diverge from the closely tracking tzdb. This is ultimately bad news for end users.
For the avoidance of doubt: I completely agree that renaming Europe/Kiev to Europe/Kyiv was the correct thing to do. My objection is to tagging tzdb releases with only commentary changes and no data changes.
Counterpoint, as a downstream maintainer I would appreciate prompt releases for popular requests such as the renaming of Europe/Kiev. Fielding requests and redirecting them to IANA has already taken more time and mindshare than me popping out a new release with updated data.
I fully agree. And there's another aspect that has not yet been discussed at all: The social and cultural aspects of such rules. Some years ago I joined a conference about the future of UTC and there was a very interesting talk by Kevin Birth (Professor at the Department of Anthropology, Queens College, CUNY), and a related discussion, which pointed out that social and cultural aspects are often not taken into account when technical standards are established or decisions on technical changes are made, which may finally lead to missing acceptance of those standards and organizations in parts of the world. U have to admit that I didn't have these facts on my mind, either, before this conference, but the more I think about it, the more I see how important this is for international cooperation and agreements. Having this in mind, I think that since the TZDB was introduced, there hasn't been a similar world-wide crisis like the current one, so this is a situation where it should be perfectly fine to make an exception from the default and make a comment-only release once. [...]
If anything, infrequent releases are more of a problem for me (of course I can't speak for other downstreams). The longer between releases, the more likely it is that my release machinery has atrophied, the more accumulated bugs need to be fixed, and under higher time pressure as the release is more likely to have some time critical change included.
That's exactly what I think, too. We have observed that with leap seconds. Years ago, when there were leap seconds every 12 or 18 months, they didn't cause any malfunctions because developers had leap seconds on their mind. Problems started after there had been several years without a leap second, because many people just forgot about them, didn't care, and when a leap second came up, there were quite some problems. This is no statement for or against leap seconds, and I don't want to start a discussion about this. I'm just trying to point out a similar case where less errors occur when things happen frequently. Martin -- Martin Burnicki Senior Software Engineer MEINBERG Funkuhren GmbH & Co. KG Email: martin.burnicki@meinberg.de Phone: +49 5281 9309-414 Linkedin: https://www.linkedin.com/in/martinburnicki/ Lange Wand 9, 31812 Bad Pyrmont, Germany Amtsgericht Hannover 17HRA 100322 Geschäftsführer/Managing Directors: Günter Meinberg, Werner Meinberg, Andre Hartmann, Heiko Gerstung Websites: https://www.meinberg.de https://www.meinbergglobal.com
I'm sure [releasing the name-only change] would calm down this discussion
immediately.
I don't doubt that. What I doubt is that it's helpful to offer the same explanation again and again. --Bill Seymour On Tue, Jun 28, 2022 at 7:54 AM Martin Burnicki via tz <tz@iana.org> wrote:
Bill Seymour via tz wrote:
It probably won't help to keep explaining the same thing over and over again. Maybe if we quit paying attention to them, they'll go away.
Hm, I wonder what you guys would do if your country was attacked by an aggressor.
The whole discussion if and why to change the spelling to Kyiv is obsolete if the change has already been made in the repo, and even though usually a new version of the DB is only released if some TZ rule was changed, it should not be too hard to simply release a new version now, due to the specific situation, and don't wait until another country decides to stick with or abolish DST.
I'm sure this would calm down this discussion immediately.
Martin -- Martin Burnicki
Senior Software Engineer
MEINBERG Funkuhren GmbH & Co. KG Email: martin.burnicki@meinberg.de Phone: +49 5281 9309-414 Linkedin: https://www.linkedin.com/in/martinburnicki/
Lange Wand 9, 31812 Bad Pyrmont, Germany Amtsgericht Hannover 17HRA 100322 Geschäftsführer/Managing Directors: Günter Meinberg, Werner Meinberg, Andre Hartmann, Heiko Gerstung Websites: https://www.meinberg.de https://www.meinbergglobal.com
I think the first mention on the mailing list that Europe/Kyiv might be preferable (but not a request for change) was this post: https://mm.icann.org/pipermail/tz/2007-May/014365.html
Considering the last name of the person who submitted the message - McDonald - only confirms that Kyiv is accepted by English-speaking people as common. But despite that, I'm telling you about an error in the tz database, not a typo or misspelling - an error. In June 2019 the name Kyiv was officially adopted by the United States Board on Geographic Names as the only correct one, which means, on the contrary, that Kiev is not a correct one, therefore there is no correct timezone for Kyiv. The other question is how important is that error correction? - The answer could have been seen in the community archive list, but the number of such requests is, I assume, significantly suppressed due to the unwillingness of the coordinator to add these requests to the list.
The ones that did, and had something new to add would have been let through. The "new" variable here is how long the error persists and affects users.
вт, 28 июн. 2022 г. в 13:46, Ian Abbott <abbotti@mev.co.uk>:
On 27/06/2022 21:32, Petro Ord wrote:
Theory and pragmatics of the tz code and data says to "Use mainstream English spelling", popular is not quite a synonym to mainstream. With that being said, Kyiv became mainstream in 1991.
You may have considered it mainstream in 1991, but the English language media took its time catching up.
I think the first mention on the mailing list that Europe/Kyiv might be preferable (but not a request for change) was this post:
https://mm.icann.org/pipermail/tz/2007-May/014365.html
Then we have to wait nearly another 7 years for a post from an actual Ukrainian (I presume their nationality from context) requesting a name change:
https://mm.icann.org/pipermail/tz/2014-April/020837.html
There has been a steady stream of requests on the list since then, but the position has always been that the most prevalent spelling in the English language should be used. That has been reviewed by the TZ Coordinator (a.k.a. the maintainer, Paul Eggert) and others several times over the intervening years and was finally deemed to have flipped over in favour of the Kyiv spelling earlier this year. It was always likely to happen sometime as the Kyiv spelling gradually gained in popularity.
How can you evaluate significance of the existing zone names, if the requests and messages are neglected? Look at the answer I've got from Paul Eggart: "The list is being moderated to suppress spam by people who are repeatedly lobbying for the spelling change. I forgot that, and cc'ed to the list. I should have just replied to you privately." That is quite intolerable to all Ukrainians and Ukraine-related issues.
I'm sure it saves a lot of bandwidth discussing a barrage of requests for a change already that was already under consideration as part of an ongoing review process. I'm sure most of those posters did not take the time to search through the archives of the mailing list for similar discussions. The ones that did, and had something new to add would have been let through.
And again, who is in charge to define the change to be important? If it is one person - what is the meaning of such discussions, if it is the community - then why is the "repeated' request ignored?
The answers to "who is in charge?" and general procedure questions is in RFC 6557 <https://www.rfc-editor.org/rfc/rfc6557.html>.
-- -=( Ian Abbott <abbotti@mev.co.uk> || MEV Ltd. is a company )=- -=( registered in England & Wales. Regd. number: 02862268. )=- -=( Regd. addr.: S11 & 12 Building 67, Europa Business Park, )=- -=( Bird Hall Lane, STOCKPORT, SK3 0XA, UK. || www.mev.co.uk )=-
On 28/06/2022 12:50, Petro Ord wrote:
I think the first mention on the mailing list that Europe/Kyiv might be preferable (but not a request for change) was this post: https://mm.icann.org/pipermail/tz/2007-May/014365.html
Considering the last name of the person who submitted the message - McDonald - only confirms that Kyiv is accepted by English-speaking people as common.
Not as common as Kiev at the time.
But despite that, I'm telling you about an error in the tz database, not a typo or misspelling - an error. In June 2019 the name Kyiv was officially adopted by the United States Board on Geographic Names as the only correct one, which means, on the contrary, that Kiev is not a correct one, therefore there is no correct timezone for Kyiv.
The names used in the TZ database are supposed to be the most prevalent versions in the English language. Names adopted by the United States Board on Geographic Names or any other official body have nothing to do with it.
The other question is how important is that error correction? - The answer could have been seen in the community archive list, but the number of such requests is, I assume, significantly suppressed due to the unwillingness of the coordinator to add these requests to the list.
Not important enough to expedite a release for the reasons already mentioned. Clocks will continue to show the correct time without this change. -- -=( Ian Abbott <abbotti@mev.co.uk> || MEV Ltd. is a company )=- -=( registered in England & Wales. Regd. number: 02862268. )=- -=( Regd. addr.: S11 & 12 Building 67, Europa Business Park, )=- -=( Bird Hall Lane, STOCKPORT, SK3 0XA, UK. || www.mev.co.uk )=-
Not as common as Kiev at the time. I disagree
Clocks will continue to show the correct time without this change. It is not the problem with the time itself. The problem is that there is no Ukraine in the tz database. And the last is proven by the number of requests that keeps saying "please correct, this is wrong"
ср, 29 июн. 2022 г. в 12:47, Ian Abbott <abbotti@mev.co.uk>:
On 28/06/2022 12:50, Petro Ord wrote:
I think the first mention on the mailing list that Europe/Kyiv might be preferable (but not a request for change) was this post: https://mm.icann.org/pipermail/tz/2007-May/014365.html
Considering the last name of the person who submitted the message - McDonald - only confirms that Kyiv is accepted by English-speaking people as common.
Not as common as Kiev at the time.
But despite that, I'm telling you about an error in the tz database, not a typo or misspelling - an error. In June 2019 the name Kyiv was officially adopted by the United States Board on Geographic Names as the only correct one, which means, on the contrary, that Kiev is not a correct one, therefore there is no correct timezone for Kyiv.
The names used in the TZ database are supposed to be the most prevalent versions in the English language. Names adopted by the United States Board on Geographic Names or any other official body have nothing to do with it.
The other question is how important is that error correction? - The answer could have been seen in the community archive list, but the number of such requests is, I assume, significantly suppressed due to the unwillingness of the coordinator to add these requests to the list.
Not important enough to expedite a release for the reasons already mentioned. Clocks will continue to show the correct time without this change.
-- -=( Ian Abbott <abbotti@mev.co.uk> || MEV Ltd. is a company )=- -=( registered in England & Wales. Regd. number: 02862268. )=- -=( Regd. addr.: S11 & 12 Building 67, Europa Business Park, )=- -=( Bird Hall Lane, STOCKPORT, SK3 0XA, UK. || www.mev.co.uk )=-
participants (18)
-
Bill Seymour -
Christos Zoulas -
Doug Ewell -
Eliot Lear -
Guy Harris -
Ian Abbott -
Jacob Pratt -
Kim Davies -
Martin Burnicki -
merlyn＠stonehenge.com -
Paul Eggert -
Paul Gilmartin -
Petro Ord -
Philip Paeps -
Stuart Bishop -
Tim Parenti -
Tom Lane -
Đoàn Trần Công Danh