proposal for new tzdb versions
In light of the previous discussions and the fact that we need a new release very soon, I propose the following: * We release 2021b pretty much as-is (with the usual release administrivia such as updating NEWS). * We also generate a separate 2021a1 version, which is like 2021a except with the Samoa change that is prompting 2021b. This version recognizes the concerns about the number of changes to pre-1970 timestamps in 2021b. I'll do this by publishing a patch to 2021a, along with a patched tarball, on my website at UCLA. Although this is effectively a fork in the short term, the idea is that it's a small fork with the intent that we'll work together to combine the two approaches in later releases, taking the abovementioned concerns into account. There is precedent for this approach, in that when there were compatibility problems with earlier releases, I generated alternate tarballs to support downstream users while they were adapting their database readers. Although the two cases are not the same, generating an alternate distribution also has the benefit of giving us time. Although I haven't had time to read all the discussions so far (and email is still rolling in), I will try to take these discussions into account when writing the NEWS entries for the two versions. After the versions are published and the dust has settled, I hope that we can incorporate some of the suggestions that have been made, as we will then have time to implement and test them. I don't want this followup discussion to take a looong time, though, as the goal is to combine the two approaches soon. Since Samoa's rules change in less than 72 hours I plan to generate these new versions soon.
On Wed, 22 Sept 2021 at 14:31, Paul Eggert via tz <tz@iana.org> wrote:
In light of the previous discussions and the fact that we need a new release very soon, I propose the following:
In view of the totality of the discussion I've read, I support this proposal for the short-term, and — after a short break — look forward to productive discussion on how best to support the different types of outputs that are needed for the long-term. -- Tim Parenti
Paul Eggert via tz <tz@iana.org> writes:
In light of the previous discussions and the fact that we need a new release very soon, I propose the following:
* We release 2021b pretty much as-is (with the usual release administrivia such as updating NEWS).
* We also generate a separate 2021a1 version, which is like 2021a except with the Samoa change that is prompting 2021b. This version recognizes the concerns about the number of changes to pre-1970 timestamps in 2021b. I'll do this by publishing a patch to 2021a, along with a patched tarball, on my website at UCLA.
"2021a1" is what a number of people would likely have done unofficially, so making it at least partially official would be better than no action at all. However, it still seems to me that this course of action is prejudging the eventual outcome. tzdb distributors who have not been paying close attention will almost certainly ship 2021b, and then we will have exactly the data instability that some of us hoped to avoid, and basically no way to correct that without creating even more instability. In short: this is better than shipping 2021b only, but not by much, because it utterly fails to account for the concerns I have. regards, tom lane
I agree with Tom's comments. We *really* don't want the disruption that would happen when some people pick up the 2021b and others pick up 2021a1; especially when it is likely that many of the people picking up 2021b won't know that they could be breaking downstream clients. There is *no* harm at all to just issuing a 2021b that has 2021a + Somoan fix right now (no other changes). That is the simple option for now. Then people have the opportunity to hash out the situation without disruption. Mark On Wed, Sep 22, 2021 at 11:44 AM Tom Lane via tz <tz@iana.org> wrote:
Paul Eggert via tz <tz@iana.org> writes:
In light of the previous discussions and the fact that we need a new release very soon, I propose the following:
* We release 2021b pretty much as-is (with the usual release administrivia such as updating NEWS).
* We also generate a separate 2021a1 version, which is like 2021a except with the Samoa change that is prompting 2021b. This version recognizes the concerns about the number of changes to pre-1970 timestamps in 2021b. I'll do this by publishing a patch to 2021a, along with a patched tarball, on my website at UCLA.
"2021a1" is what a number of people would likely have done unofficially, so making it at least partially official would be better than no action at all. However, it still seems to me that this course of action is prejudging the eventual outcome. tzdb distributors who have not been paying close attention will almost certainly ship 2021b, and then we will have exactly the data instability that some of us hoped to avoid, and basically no way to correct that without creating even more instability.
In short: this is better than shipping 2021b only, but not by much, because it utterly fails to account for the concerns I have.
regards, tom lane
Yeah, so far I don't see any justification in here for creating this short term fork — a reorganization of the historical data does not exactly seem to be something that is important in the short term and the cost will be quite high. I'll also note that the proposed version 2021a1 is likely going to cause problems all by itself. In the Downloading the tz database <https://data.iana.org/time-zones/tz-link.html#download> section of tz-link it says:
Since 1996, each version has been a four-digit year followed by lower-case letter (a through z, then za through zz, then zza through zzz, and so on). Since version 2016h, each release has contained a text file named "version" whose first (and currently only) line is the version.
This is not exactly a guarantee, but 2021a1 does violate that nomenclature, which will likely break scripts that rely on it (I have scripts that actively assert that the version numbering follows this convention, for example). I have personally been in the camp of giving Paul the strong benefit of the doubt on many of these concerns, but I do think it would buy a lot of good will to simply cut a release for 2021a + Samoan changes and call that 2021b and forestall releasing the controversial changes until resolution is reached (ideally with lots of notice, so people have time to update their assumptions about the stability of historical data as distributed). Best, Paul On 9/22/21 15:06, Howard Hinnant via tz wrote:
On Sep 22, 2021, at 2:30 PM, Paul Eggert via tz<tz@iana.org> wrote:
Although this is effectively a fork in the short term, A fork is a big cost. What is the benefit that outweighs this cost?
Howard
On 22 September 2021 19:30:38 BST, Paul Eggert via tz <tz@iana.org> wrote:
In light of the previous discussions and the fact that we need a new release very soon, I propose the following:
* We release 2021b pretty much as-is (with the usual release administrivia such as updating NEWS).
* We also generate a separate 2021a1 version, which is like 2021a except with the Samoa change that is prompting 2021b. This version recognizes the concerns about the number of changes to pre-1970 timestamps in 2021b. I'll do this by publishing a patch to 2021a, along with a patched tarball, on my website at UCLA.
I can't remember the last time there was a number after the version letter (so 2004, at the latest), and none of the tooling that I've been involved with will know how to handle this. By deviating from the expected norm, albeit potentially naively, I'm afraid it will cause more problems than it solves. I'd also worry that people that don't pay attention will suddenly get tzdata that is in their view "missing data". I would therefore urge you to have a 2021b which is 2021a with the required rules set update only. cheers Derick
Paul Eggert via tz <tz@iana.org> writes:
In light of the previous discussions and the fact that we need a new release very soon, I propose the following:
* We release 2021b pretty much as-is (with the usual release administrivia such as updating NEWS).
* We also generate a separate 2021a1 version, which is like 2021a except with the Samoa change that is prompting 2021b. This version recognizes the concerns about the number of changes to pre-1970 timestamps in 2021b. I'll do this by publishing a patch to 2021a, along with a patched tarball, on my website at UCLA.
I think two releases is a good compromise and interim step while the larger discussion continues. My only recommendation would be to reverse the names and release what you were planning on calling 2021a1 as 2021b, and release the current main branch as 2021b1. Rationale: If tzdata were using semver, the current main branch would warrant a major version bump because a default build includes some changes that are unusual for tzdata updates and may warrant some special care or consideration. Version numbers are a communications tool to tell people which releases are safe to apply on autopilot and which require more attention. tzdata doesn't use semver, so we don't have a natural place in the version number to put this information, but I think one of the goals here is a similar sort of signaling. One release requires nothing of downstream consumers other than their normal update process and introduces no new issues they need to be aware of. The other is a more substantial change for which they should read the NEWS entry carefully. Given the version numbering scheme, I think releasing the minimal change as 2021b and the larger change as 2021b1 conveys that as best you can. The "normal" version number is the "routine" update that can be applied on autopilot with no review of build or integration systems. The "unusual" version number 2021b1, which might prompt a pause and closer attention, is the release that warrants that pause, closer attention, and a close reading of NEWS. -- Russ Allbery (eagle@eyrie.org) <https://www.eyrie.org/~eagle/>
* Paul Eggert via tz:
* We also generate a separate 2021a1 version, which is like 2021a except with the Samoa change that is prompting 2021b. This version recognizes the concerns about the number of changes to pre-1970 timestamps in 2021b. I'll do this by publishing a patch to 2021a, along with a patched tarball, on my website at UCLA.
I'm slightly worried that people have grown to depend on the \d+[a-z]+ format for version numbers, so this choice of version might break some things. Thanks, Florian
Paul Eggert via tz <tz@iana.org> wrote on Wed, 22 Sep 2021 at 14:30:38 EDT in <2184234f-a2f3-7bbe-a9da-db21bbac7c71@cs.ucla.edu>:
In light of the previous discussions and the fact that we need a new release very soon, I propose the following:
* We release 2021b pretty much as-is (with the usual release administrivia such as updating NEWS).
* We also generate a separate 2021a1 version, which is like 2021a except with the Samoa change that is prompting 2021b. This version recognizes the concerns about the number of changes to pre-1970 timestamps in 2021b. I'll do this by publishing a patch to 2021a, along with a patched tarball, on my website at UCLA.
I don't understand why we would release 2021b as-proposed. What is the timliness that requires doing that? Making that release will make it *far* more difficult to undo, when most downstream consumers adopt it. It effectively pretermits the discussion we are having. I think it is imprudent, unwise, and a bit unfair. I had drafted some comments from the back of my brain on Monday, and never made them coherent, but perhaps here's the time to offer them, imperfect as they remain: The practice of making commits to the master source control repository for the release branch of the project while simultaneously characterizing them as “experimental" is a big part of the problem of how we got here. It confers a massive first-mover advantage to those commits, which have not necessarily had the benefit of conensus (indeed, it seems often they are committed and then concensus is sought after). This is not reasonable, and it means that any release cut from the repo can (and apparently will) contain experimental changes that are unvetted and do not hold conensus. Those kinds of changes ought to be made on another branch, not the branch from which releases are cut. -- jhawk@alum.mit.edu John Hawkinson
Paul Goyette via tz <tz@iana.org> wrote on Fri, 24 Sep 2021 at 12:13:43 EDT in <Pine.NEB.4.64.2109240911420.16051@speedy.whooppee.com>:
a: Paul move his changes to a branch and release 2021b as 2021a+Samoa
On Wednesday (so long ago), I asked why we would *not* do that. There was no answer: John Hawkinson <jhawk@alum.mit.edu> wrote on Wed, 22 Sep 2021 at 15:22:21 EDT in <20210922192221.GE41824@alum.mit.edu>:
I don't understand why we would release 2021b as-proposed. What is the timliness that requires doing that?
Making that release will make it *far* more difficult to undo, when most downstream consumers adopt it.
It effectively pretermits the discussion we are having. I think it is imprudent, unwise, and a bit unfair.
So again, why would we not do this? What interest does it serve to do otherwise? -- jhawk@alum.mit.edu John Hawkinson
On 9/24/21 9:16 AM, John Hawkinson wrote:
So again, why would we not do this? What interest does it serve to do otherwise?
Unfortunately I haven't had time to answer each individual message. The brief answer to your question is that it is relatively urgent for us to address the equity issue. So far this issue has been mostly limited to this mailing list, but it's almost sure to come out in the popular press, as the recent flurry of messages has caused outsiders to pay attention to the issue. (I know this because they're contacting me privately.) I don't want the resulting headlines to cast aspersions on IANA, on the contributors to this discussion, or on the immediate consumers of the database. We need to show that we're addressing the equity problem. This means shouldn't continue to come out with new releases without doing anything about a real equity issue that we've known about for several months.
Paul Eggert via tz <tz@iana.org> writes:
On 9/24/21 9:16 AM, John Hawkinson wrote:
So again, why would we not do this? What interest does it serve to do otherwise?
Unfortunately I haven't had time to answer each individual message.
The brief answer to your question is that it is relatively urgent for us to address the equity issue.
So far this issue has been mostly limited to this mailing list, but it's almost sure to come out in the popular press, as the recent flurry of messages has caused outsiders to pay attention to the issue. (I know this because they're contacting me privately.)
It's certainly unfortunate that we still don't have a satisfactory solution, but it's been clear since May that a large fraction of the mailing list doesn't agree with your solution. Forcing the issue under time pressure is just going to make things worse. More than that, your solution is going to result in an effective fork. Even if there's not an actual competing upstream, the probability that some significant fraction of repackagers will start using backzone is going to create confusion on the ground that's indistinguishable from a fork. You should be worrying more about the headlines that will result from *that*. regards, tom lane
On 9/24/21 2:41 PM, Tom Lane wrote:
Even if there's not an actual competing upstream, the probability that some significant fraction of repackagers will start using backzone is going to create confusion on the ground that's indistinguishable from a fork. You should be worrying more about the headlines that will result from *that*.
*Those* headlines I'm willing to put up with. They'll be a lot less ugly than the ones I'm worried about. I'm reasonably confident that major repackagers are also sensitive to the issue of equity, and will be willing to follow a reasonable lead. Although you're right that some repackagers may go their own way in the short term, I hope and have reason to believe that we'll all come up with a mutually acceptable solution in the medium to longer term. In the meantime all I can do is continue to say, "You shouldn't use 'backzone'." That's been my advice all along. (Not that everybody listens to my advice....)
On Fri, 24 Sept 2021 at 21:51, Paul Eggert via tz <tz@iana.org> wrote:
On 9/24/21 9:16 AM, John Hawkinson wrote:
So again, why would we not do this? What interest does it serve to do otherwise?
Unfortunately I haven't had time to answer each individual message.
The brief answer to your question is that it is relatively urgent for us to address the equity issue.
I think the interesting question at this point is whether you feel it is so urgent that it has to be addressed *today* as opposed to a few weeks time. Taking into account the near-unanimous rejection of releasing the link merges today. Stephen
On 9/24/21 2:42 PM, Stephen Colebourne via tz wrote:
I think the interesting question at this point is whether you feel it is so urgent that it has to be addressed*today* as opposed to a few weeks time.
Yes, weeks will be too long for the relatively-small change embodied by <https://mm.icann.org/pipermail/tz/2021-September/030743.html>. We should be out in front of this issue. Desperately trying to delay is not a winning strategy. Plus, being fair(er) is the right thing to do.
(sending to list, was direct reply first time) Paul, with due respect please remember to consider tone. You have previously compared positions other than your own to denying people COVID-19 vaccines and are now calling people solely interested in discussion before a major change are "desperate". I do not find this to be respectful discourse and imagine that I am not the only one who has read your comments this way. Jacob Pratt On Fri, Sep 24, 2021, 18:55 Paul Eggert via tz <tz@iana.org> wrote:
On 9/24/21 2:42 PM, Stephen Colebourne via tz wrote:
I think the interesting question at this point is whether you feel it is so urgent that it has to be addressed*today* as opposed to a few weeks time.
Yes, weeks will be too long for the relatively-small change embodied by <https://mm.icann.org/pipermail/tz/2021-September/030743.html>. We should be out in front of this issue. Desperately trying to delay is not a winning strategy. Plus, being fair(er) is the right thing to do.
On 9/24/21 4:12 PM, Jacob Pratt wrote:
You have previously compared positions other than your own to denying people COVID-19 vaccines
I am afraid that you have that backwards. As someone else pointed out, in my analogy, it was my position (not other people's positions) that was analogized to denying vaccines. In other words, by using that analogy I made myself look bad and I was being generous to the other side.
and are now calling people solely interested in discussion before a major change are "desperate".
I intended the word "desperately" to refer to myself, as in, I didn't want to be trying desperately to delay. My apologies if the word was interpreted otherwise.
On Fri, 24 Sept 2021 at 23:54, Paul Eggert via tz <tz@iana.org> wrote:
On 9/24/21 2:42 PM, Stephen Colebourne via tz wrote:
I think the interesting question at this point is whether you feel it is so urgent that it has to be addressed*today* as opposed to a few weeks time.
Yes, weeks will be too long for the relatively-small change embodied by <https://mm.icann.org/pipermail/tz/2021-September/030743.html>. We should be out in front of this issue. Desperately trying to delay is not a winning strategy. Plus, being fair(er) is the right thing to do.
I'm encouraging you to delay because pretty much the entire list has asked you to delay. You are quite literally saying to the entire list "stuff you, I'm right". I note that you have yet to engage with my sincerely held view that merging zones in this way makes the database less fair. Your view of fairness is not the only one. Stephen
On 9/24/21 4:40 PM, Stephen Colebourne via tz wrote:
I note that you have yet to engage with my sincerely held view that merging zones in this way makes the database less fair.
Unfortunately we've exchanged so many emails on the subject that I'm sure I've dropped some. Perhaps you're referring to this email? https://mm.icann.org/pipermail/tz/2021-September/030689.html In it, you wrote, "current rules result in what I consider to be an inequitable outcome where Berlin is favoured over Oslo", and later wrote "I have a good final position state for tzdb in my head, but I don't want to write it to the list until everything is calmer. (My proposal meets both your and my equity viewpoints)." I understood that email to mean that you had an alternative definition of equity, and that you were planning to share it with us when things are calmer. If that understanding is correct, I welcome discussing it when it's available, as I also want to work together to something that we can agree on. Being pressed for time, though, I thought discussion of an as-yet-unpresented position was premature. If my understanding of your email was incorrect, I'm sorry about that.
I agree with pretty much everyone else rejecting this proposal - Tom and Mark explained why very clearly. This approach will really screw up downstream processes, with many picking up 2021b without even realising or having a chance to change it. Please release 2021b as 2021a plus the minimum necessary changes. The controversial data reorganisation simply does not need a release at this point. Stephen On Wed, 22 Sept 2021 at 19:31, Paul Eggert via tz <tz@iana.org> wrote:
In light of the previous discussions and the fact that we need a new release very soon, I propose the following:
* We release 2021b pretty much as-is (with the usual release administrivia such as updating NEWS).
* We also generate a separate 2021a1 version, which is like 2021a except with the Samoa change that is prompting 2021b. This version recognizes the concerns about the number of changes to pre-1970 timestamps in 2021b. I'll do this by publishing a patch to 2021a, along with a patched tarball, on my website at UCLA.
Although this is effectively a fork in the short term, the idea is that it's a small fork with the intent that we'll work together to combine the two approaches in later releases, taking the abovementioned concerns into account.
There is precedent for this approach, in that when there were compatibility problems with earlier releases, I generated alternate tarballs to support downstream users while they were adapting their database readers. Although the two cases are not the same, generating an alternate distribution also has the benefit of giving us time.
Although I haven't had time to read all the discussions so far (and email is still rolling in), I will try to take these discussions into account when writing the NEWS entries for the two versions.
After the versions are published and the dust has settled, I hope that we can incorporate some of the suggestions that have been made, as we will then have time to implement and test them. I don't want this followup discussion to take a looong time, though, as the goal is to combine the two approaches soon.
Since Samoa's rules change in less than 72 hours I plan to generate these new versions soon.
My current advice to Joda-Time users is as follows: DO NOT INSTALL 2021b until I confirm otherwise. https://twitter.com/jodastephen/status/1440838718726684679 (I'm going to bed soon, so I have to pre-empt any release overnight.) Because of the way Joda-Time works wrt actively changing the ID a user requests to the canonical form, releasing 2021b as-is will cause serious application issues where users pass in Oslo and get Berlin. eg. DateTimeZone zone = DateTimeZone.forID("Europe/Oslo"); System.out.println(zone); will print "Europe/Berlin" These IDs are frequently placed into databases, so the effects will be long-lasting. Literally millions of Java applications are at risk if 2021b comes out with the disputed changes in the next few hours. Please, please, please just release 2021b as the minimum changes on top of 2021a, and do not release the current main branch. Stephen On Wed, 22 Sept 2021 at 23:40, Stephen Colebourne <scolebourne@joda.org> wrote:
I agree with pretty much everyone else rejecting this proposal - Tom and Mark explained why very clearly.
This approach will really screw up downstream processes, with many picking up 2021b without even realising or having a chance to change it.
Please release 2021b as 2021a plus the minimum necessary changes. The controversial data reorganisation simply does not need a release at this point.
Stephen
On Wed, 22 Sept 2021 at 19:31, Paul Eggert via tz <tz@iana.org> wrote:
In light of the previous discussions and the fact that we need a new release very soon, I propose the following:
* We release 2021b pretty much as-is (with the usual release administrivia such as updating NEWS).
* We also generate a separate 2021a1 version, which is like 2021a except with the Samoa change that is prompting 2021b. This version recognizes the concerns about the number of changes to pre-1970 timestamps in 2021b. I'll do this by publishing a patch to 2021a, along with a patched tarball, on my website at UCLA.
Although this is effectively a fork in the short term, the idea is that it's a small fork with the intent that we'll work together to combine the two approaches in later releases, taking the abovementioned concerns into account.
There is precedent for this approach, in that when there were compatibility problems with earlier releases, I generated alternate tarballs to support downstream users while they were adapting their database readers. Although the two cases are not the same, generating an alternate distribution also has the benefit of giving us time.
Although I haven't had time to read all the discussions so far (and email is still rolling in), I will try to take these discussions into account when writing the NEWS entries for the two versions.
After the versions are published and the dust has settled, I hope that we can incorporate some of the suggestions that have been made, as we will then have time to implement and test them. I don't want this followup discussion to take a looong time, though, as the goal is to combine the two approaches soon.
Since Samoa's rules change in less than 72 hours I plan to generate these new versions soon.
On Sep 22, 2021, at 9:03 PM, Stephen Colebourne via tz <tz@iana.org> wrote:
Because of the way Joda-Time works wrt actively changing the ID a user requests to the canonical form, releasing 2021b as-is will cause serious application issues where users pass in Oslo and get Berlin.
eg. DateTimeZone zone = DateTimeZone.forID("Europe/Oslo"); System.out.println(zone); will print "Europe/Berlin"
Fwiw, C++20 has exactly the same issue, with different syntax of course. You can ask for a time_zone by name. If that name is a link, you get the aliased time_zone. If you ask for that time_zone’s name, you get the time_zone name, not the link name. Howard
Date: Wed, 22 Sep 2021 11:30:38 -0700 From: Paul Eggert via tz <tz@iana.org> Message-ID: <2184234f-a2f3-7bbe-a9da-db21bbac7c71@cs.ucla.edu> | * We release 2021b pretty much as-is | | * We also generate a separate 2021a1 version, | I'll do this by publishing a patch to 2021a, along with a patched | tarball, on my website at UCLA. | | Although this is effectively a fork in the short term, It is, but it is a trivial one, as no-one is even going to notice the oddly named version on a UCLA server - so what you're suggesting is to more or less presume that the "as-is" (which means, as-isn't really as that version has never been released) becomes that new version, and you're totally ignoring all the "revert to 2021a for now" requests from just about everyone. | There is precedent for this approach, in that when there were | compatibility problems with earlier releases, I generated alternate | tarballs to support downstream users while they were adapting their | database readers. Although the two cases are not the same, generating an | alternate distribution also has the benefit of giving us time. They're not even close to the same - that way provided two different methods to arrive at essentially the same output data, one for people with sane up to date parsers, and one for those lagging behind. That was fine, and apart from the slight amount of extra (self-imposed) work for those with parsers that didn't parse correctly (and your extra effort in generating support for them) that harmed nothing. | Since Samoa's rules change in less than 72 hours I plan to generate | these new versions soon. Don't. Just generate the thing you were going to call 2021a1, call it 2021b, and distribute it the normal way. If there is any justification at all for the other changes (which I fail to see - it certainly is not that bizarre discrimination argument) then that can be considered before 2021c (or more likely some 2022 version) - I certainly cannot see any urgency in any of those changes, even if they had some merit. kre
On 2021-09-23 02:30:38 (+0800), Paul Eggert via tz wrote:
In light of the previous discussions and the fact that we need a new release very soon, I propose the following:
* We release 2021b pretty much as-is (with the usual release administrivia such as updating NEWS).
* We also generate a separate 2021a1 version, which is like 2021a except with the Samoa change that is prompting 2021b. This version recognizes the concerns about the number of changes to pre-1970 timestamps in 2021b. I'll do this by publishing a patch to 2021a, along with a patched tarball, on my website at UCLA.
This would be a terrible idea. Please consider the alternative approach I suggested yesterday. On 2021-09-22 18:32:10 (+0800), Philip Paeps via tz wrote:
To avoid repo-churn on main, I would suggest releasing 2021b from a branch made before the disputed changes in May, with the recent non-controversial changes cherry-picked from main. An appropriate NEWS entry can be added on main to explain.
Several people have pointed out the technical shortcomings of your proposal. Fundamentally though, it would push changes into the wild for which no consensus exists.
After the versions are published and the dust has settled [...]
Publishing the current state of main as 2021b will not settle the dust.
Since Samoa's rules change in less than 72 hours I plan to generate these new versions soon.
Please don't. Philip -- Philip Paeps Senior Reality Engineer Alternative Enterprises
Dear Paul Eggert, On Wednesday, 22 September 2021 20:30:38 CEST Paul Eggert via tz wrote:
In light of the previous discussions and the fact that we need a new release very soon, I propose the following:
* We release 2021b pretty much as-is (with the usual release administrivia such as updating NEWS).
* We also generate a separate 2021a1 version, which is like 2021a except with the Samoa change that is prompting 2021b. This version recognizes the concerns about the number of changes to pre-1970 timestamps in 2021b. I'll do this by publishing a patch to 2021a, along with a patched tarball, on my website at UCLA.
Please at least swap the names of the two releases. In my eyes, there seemed to have been a consensus to let the discussion cool down and then find a way forward. Pushing controversial changes out in the main line won't help the following discussion. There is no immediate need to push any changes except the Samoa rule changes out _right now_, so please incorporate just those into 2021b and let's reconcile on how to proceed thereafter.
Although this is effectively a fork in the short term, the idea is that it's a small fork with the intent that we'll work together to combine the two approaches in later releases, taking the abovementioned concerns into account.
There is precedent for this approach, in that when there were compatibility problems with earlier releases, I generated alternate tarballs to support downstream users while they were adapting their database readers. Although the two cases are not the same, generating an alternate distribution also has the benefit of giving us time.
That's a good idea, although your suggested naming scheme will potentially and nunnecessarly cause chaos for all those who did not pay attention to this mailing list and just rely on the usual naming format or blindly just consume the data. Especially with the new information in the emails emails stating issues with time_zone by name in C++20 and java DateTimeZone.forID, please honestly take this into consideration.
From affected Europe/Copenhagen, Jürgen
-- Jürgen Appel Research Scientist, Time & Frequency Denmark's National Metrology Institute Dansk Fundamental Metrologi, DFM A/S (dfm.dk) Kogle Allé 5 DK-2970 Hørsholm Denmark Mobile: +45 25459049 Email: jap@dfm.dk VAT: DK-29217939
For Android having 2021a1 and 2021b would be inconvenient. Because there are hardcoded places which expect that tzdata version is exactly 5 characters. And we can't update that code along with time zone files. Most feasible way we see is to release it as "2021a Android revision 1", but that revision field is not exposed by any APIs. There will be inconsistencies between different APIs on "What tzdb release are you using". Personally I agree with Tom. Releasing 2021b as 2021a + Samoa changes is less disruptive. On Wed, 22 Sept 2021 at 19:31, Paul Eggert via tz <tz@iana.org> wrote:
In light of the previous discussions and the fact that we need a new release very soon, I propose the following:
* We release 2021b pretty much as-is (with the usual release administrivia such as updating NEWS).
* We also generate a separate 2021a1 version, which is like 2021a except with the Samoa change that is prompting 2021b. This version recognizes the concerns about the number of changes to pre-1970 timestamps in 2021b. I'll do this by publishing a patch to 2021a, along with a patched tarball, on my website at UCLA.
Although this is effectively a fork in the short term, the idea is that it's a small fork with the intent that we'll work together to combine the two approaches in later releases, taking the abovementioned concerns into account.
There is precedent for this approach, in that when there were compatibility problems with earlier releases, I generated alternate tarballs to support downstream users while they were adapting their database readers. Although the two cases are not the same, generating an alternate distribution also has the benefit of giving us time.
Although I haven't had time to read all the discussions so far (and email is still rolling in), I will try to take these discussions into account when writing the NEWS entries for the two versions.
After the versions are published and the dust has settled, I hope that we can incorporate some of the suggestions that have been made, as we will then have time to implement and test them. I don't want this followup discussion to take a looong time, though, as the goal is to combine the two approaches soon.
Since Samoa's rules change in less than 72 hours I plan to generate these new versions soon.
On Thu, 23 Sep 2021, Almaz Mingaleev via tz wrote:
For Android having 2021a1 and 2021b would be inconvenient. Because there are hardcoded places which expect that tzdata version is exactly 5 characters. And we can't update that code along with time zone files.
If so, you already have a potential problem, since in a busy year of changes we would have ..., 2021y, 2021z, 2021za, 2021zb, ... +--------------------+--------------------------+----------------------+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | paul@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoyette@netbsd.org | | | | pgoyette99@gmail.com | +--------------------+--------------------------+----------------------+
On 9/23/21 6:59 AM, Almaz Mingaleev wrote:
For Android having 2021a1 and 2021b would be inconvenient. Because there are hardcoded places which expect that tzdata version is exactly 5 characters. And we can't update that code along with time zone files.
OK, but can you please fix this in Android? That is, please put in a bug report or whatever it takes to start the machinery to fix things. You don't need to fix Android right this second, but please don't put it off until the year 9999 either, as the sorts of changes that we have been discussing post-2021b are very likely to generate version numbers longer than 5 characters in the not-as-distant-as-the-year-9999 future. Plus, the guidelines already say that release IDs can be more than 5 characters. Thanks.
Yes, I've filed a bug for that. Given the fact that Android technically does not follow guidelines (and 2021a1 possibility), I will try to fix that in Android 13. But we won't be able to deliver that change for already released devices. Thanks, Almaz On Fri, 24 Sept 2021 at 17:23, Paul Eggert <eggert@cs.ucla.edu> wrote:
On 9/23/21 6:59 AM, Almaz Mingaleev wrote:
For Android having 2021a1 and 2021b would be inconvenient. Because there are hardcoded places which expect that tzdata version is exactly 5 characters. And we can't update that code along with time zone files.
OK, but can you please fix this in Android? That is, please put in a bug report or whatever it takes to start the machinery to fix things.
You don't need to fix Android right this second, but please don't put it off until the year 9999 either, as the sorts of changes that we have been discussing post-2021b are very likely to generate version numbers longer than 5 characters in the not-as-distant-as-the-year-9999 future. Plus, the guidelines already say that release IDs can be more than 5 characters.
Thanks.
participants (17)
-
Almaz Mingaleev -
Derick Rethans -
Florian Weimer -
Howard Hinnant -
Jacob Pratt -
John Hawkinson -
Jürgen Appel -
Mark Davis ☕️ -
Paul Eggert -
Paul Ganssle -
Paul Goyette -
Philip Paeps -
Robert Elz -
Russ Allbery -
Stephen Colebourne -
Tim Parenti -
Tom Lane