Error Correction Request: Europe/Kiev to Europe/Kyiv
Hello, Please be aware that 'Kiev' is an error. The correct name is 'Kyiv'. When are you planning to correct the mistake? Please advise. Best regards, -- Iavanka Kvikta Russia is a terrorist country and I am not afraid to say it!
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). PS. This is a repeat of email originally posted here: https://mm.icann.org/pipermail/tz/2022-June/031510.html
Hello Thank you Since there is no schedule, do you have some standard (common) release period? For example, at least once a year. Sincerely, -- Iavanka Kvikta Russia is a terrorist country and I am not afraid to say it! пн, 4 лип. 2022 р. о 20:53 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).
PS. This is a repeat of email originally posted here:
On 7/4/22 13:02, Ivanka Kvitka wrote:
Since there is no schedule, do you have some standard (common) release period? For example, at least once a year.
We'll issue a new TZDB release well before a year from now, as Iran is changing their DST rules effective 22 March 2023. Also, more-urgent changes will likely arrive before then, or perhaps the accumulation of non-urgent changes will be enough to justify a release. Although there's no standard schedule, one can estimate from recent history: 5 releases in 2021 6 releases in 2020 3 releases in 2019 9 releases in 2018 3 releases in 2017
Thank you Well, there were no less than 3 releases within 5 years, so there is a chance the correction will be seen this year. Best wishes, -- Iavanka Kvikta Russia is a terrorist country and I am not afraid to say it пн, 4 лип. 2022 р. о 21:15 Paul Eggert <eggert@cs.ucla.edu> пише:
On 7/4/22 13:02, Ivanka Kvitka wrote:
Since there is no schedule, do you have some standard (common) release period? For example, at least once a year.
We'll issue a new TZDB release well before a year from now, as Iran is changing their DST rules effective 22 March 2023. Also, more-urgent changes will likely arrive before then, or perhaps the accumulation of non-urgent changes will be enough to justify a release.
Although there's no standard schedule, one can estimate from recent history:
5 releases in 2021
6 releases in 2020
3 releases in 2019
9 releases in 2018
3 releases in 2017
-- Iavanka Kvikta Russia is a terrorist country and I am not afraid to say it!
On Mon, Jul 4, 2022 at 11:16 AM Paul Eggert via tz <tz@iana.org> wrote:
On 7/4/22 13:02, Ivanka Kvitka wrote:
Since there is no schedule, do you have some standard (common) release period? For example, at least once a year.
We'll issue a new TZDB release well before a year from now, as Iran is changing their DST rules effective 22 March 2023. Also, more-urgent changes will likely arrive before then, or perhaps the accumulation of non-urgent changes will be enough to justify a release.
Although there's no standard schedule, one can estimate from recent history:
5 releases in 2021 6 releases in 2020 3 releases in 2019 9 releases in 2018 3 releases in 2017
Looking at it another way, since 2000, there has been at least one release in October of each year except for 2019, though there was a September release that year. March releases also occurred each year except: 2004, which had a May release; 2002, 2006, and 2020, which had an April release; and 2021, which had a September release. -- Alan Mintz <Alan.Mintz@gMail.com>
On Jul 4, 2022, at 14:15, Paul Eggert via tz <tz@iana.org> wrote:
We'll issue a new TZDB release well before a year from now, as Iran is changing their DST rules effective 22 March 2023. Also, more-urgent changes will likely arrive before then, or perhaps the accumulation of non-urgent changes will be enough to justify a release.
This does beg an interesting question. In ‘theory.html’, there is strong encouragement to the authorities that set civil timekeeping rules to allow ample advance notice of changes, with at least one year in advance being the base recommendation. Consider an example where a change has been duly notified to this group a year in advance, vetted to be accurate and implemented in the development version. Is there policy somewhere that states how long before the effective date of the change a release should be cut? I ask because of course shepherding the change through TZDB is merely the first step of a much longer process: the various downstream maintainers must test and package the update (a process that in itself can involve multiple parties and stages —e.g. Android), then the resulting updates must be distributed and (in many cases) manually applied by each end user. On the basis of the above, how much time would reasonably be “enough” to allow the downstream channels to process a new release? Cheers! |---------------------------------------------------------------------| | Frederick F. Gleason, Jr. | Chief Developer | | | Paravel Systems | |---------------------------------------------------------------------| | A room without books is like a body without a soul. | | | | -- Cicero | |---------------------------------------------------------------------|
On Tue, 5 Jul 2022 at 12:28, Fred Gleason via tz <tz@iana.org> wrote:
Is there policy somewhere that states how long before the effective date of the change a release should be cut?
There is not. And since our effective floor is two releases per year (or one per "silly season", as it were) there's no strong reason to impose one. I mentioned some specific examples in https://mm.icann.org/pipermail/tz/2022-July/031574.html As such, one could make the case that we operate in minimal chunks of about 6 months each. The benefit to a country for announcing a change with more than ~6 months' notice is the reasonable assurance that, even without any other urgency, the change will hit a release no later than the end of the next "silly season" after the announcement, which will tend to be between 1 and 6 months before it takes effect depending on the exact timing. Similarly, the benefit for announcing more than ~12 months out is a release lead time of 7 to 12 months, and upward in 6-month increments. (Now, depending on the vagaries of any given "silly season" and the exact dates things arrive and go into effect, whatever might make it into any given release one year might miss a similar release in another, but the general principle still holds.) And the benefit for project and downstream maintainers is that none of us have to do anything special or undertake any urgent work in order to achieve those lead times. Of course, the corollary which should be obvious to regular readers of this list is that if you announce changes with less than ~6 months' notice, you're guaranteed nothing. ;) As that describes most of our changes — typically made during the "silly seasons" themselves — they can be informally classified on a sliding scale of urgency depending on when they arrive relative to their effect. Those a bit further out might prompt us to wait a bit to see if we can batch it with something else that comes in later, saving us all some maintenance burden, while those closer to their effective dates will tend to prompt that a release be cut more urgently (within reason). In practice, readers will note that we tend to keep good tabs on when the data in the most recent release is about to "expire" and accelerate or decelerate accordingly. Adding any arbitrary target such as "release changes 30 days ahead of effect" wouldn't help, as that would create needless artificial urgency and resultant churn on any changes that would arrive at 31 days out, while doing nothing to help those that would arrive at 29 days. -- Tim Parenti
On Jul 5, 2022, at 15:28, Tim Parenti <tim@timtimeonline.com> wrote:
There is not. And since our effective floor is two releases per year (or one per "silly season", as it were) there's no strong reason to impose one. I mentioned some specific examples in https://mm.icann.org/pipermail/tz/2022-July/031574.html <https://mm.icann.org/pipermail/tz/2022-July/031574.html> Thank you. Very helpful!
Cheers! |---------------------------------------------------------------------| | Frederick F. Gleason, Jr. | Chief Developer | | | Paravel Systems | |---------------------------------------------------------------------| | A room without books is like a body without a soul. | | | | -- Cicero | |---------------------------------------------------------------------|
participants (5)
-
Alan Mintz -
Fred Gleason -
Ivanka Kvitka -
Paul Eggert -
Tim Parenti