[tz] proposal for new tzdb versions
scolebourne at joda.org
Thu Sep 23 01:03:36 UTC 2021
My current advice to Joda-Time users is as follows: DO NOT INSTALL
2021b until I confirm otherwise.
(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.
DateTimeZone zone = DateTimeZone.forID("Europe/Oslo");
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.
On Wed, 22 Sept 2021 at 23:40, Stephen Colebourne <scolebourne at 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
> Please release 2021b as 2021a plus the minimum necessary changes. The
> controversial data reorganisation simply does not need a release at
> this point.
> On Wed, 22 Sept 2021 at 19:31, Paul Eggert via tz <tz at 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.
More information about the tz