Stephen Colebourne

Just to note that Strata now insists that the x and y values are sorted.

The official release 2021b of TZDB contains changes that would negatively affect Joda-Time users. If adopted it would be impossible to hold identifiers such as `Europe/Bratislava`, `Europe/Zagreb` and `America/Guadeloupe` (and...

Release v2.10.12 of Joda-Time contains timezone data from a [fork of TZDB](https://github.com/JodaOrg/tz) that reverts both the problematic changes listed above. This is not an ideal situation, and there is work...

Release v2.10.14 of Joda-Time uses [global-tz](https://github.com/JodaOrg/global-tz), which is derived from the IANA TZDB. The global-tz project reinstates all the data that has been systematically removed from IANA TZDB over the...

Release v2.11.0 also uses global-tz. Closing this as we now have a strategy going forward.

This is not an unreasonable enhancement request. However, now Java 8 is out, Joda-Time is essentially considered a finished project, and I have no personal plans to work on enhancments,

Any change to Joda-Time would involve a full global solution based on a `Locale`, as this doesn't just affect the US. There is no particularly good place to integrate the...

The JDK's behaviour is more complex than this. It eliminates changes prior to 1900, which is not the same as removing LMT.

I'm happy to review a smallish PR in the area, although I do think it will be tricky to do. I imagine it would require capturing the TZDB data for...

It would be possible to change the notzdb version of Joda-Time to contain the UTC provider. It would be a fair bit of work solely for an edge case of...