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.