[jdk21u-dev] RFR: 8339637: (tz) Update Timezone Data to 2024b

[Andrew John Hughes]

On Fri, 8 Nov 2024 12:36:19 GMT, Goetz Lindenmaier <goetz at openjdk.org> wrote:

> I backport this for parity with 21.0.6-oracle.
> The documentation of the tz update says that it is not needed 
> necessarily, but a cleanup of various information. I think 
> we should go along here. It seems to bring a row of visible changes, 
> and it's good if this can be mapped to the same update everywhere.
> Also, this will simplify later tz updates, which happen regularly.
> 
> CSR for update versions available.
> 
> This is a Backport of the [jdk23u version](https://github.com/openjdk/jdk23u/commit/73b2341c670f98fb130c57f80eb1461226da1985), as the [jdk24 version](https://github.com/openjdk/jdk/commit/ebc17c7c8d6febd5a887309d1b7a466bcd2cc0a9) contains
> changes breaking the Java standard.  As I understand this only
> affects Java 8. But Oracle avoided to bring these changes to 23,
> so we should not do that in 21, either.
> 
> In detail, the 23u version omits backport of changes to 
> src/java.base/share/classes/java/time/ZoneId.java
> and src/java.base/share/classes/sun/util/calendar/ZoneInfoFile.java.
> 
> In the tests changes to test/jdk/java/time/tck/java/time/TCKZoneId.java and
> test/jdk/java/util/TimeZone/OldIDMappingTest.java are omited, and
> test/jdk/sun/util/calendar/zi/TestZoneInfo310.java is modified differently. File 
> test/jdk/sun/util/calendar/zi/tzdata_jdk/tz2024b_overridden_zones
> is added in 23. The change to test/jdk/sun/util/resources/TimeZone/Bug4848242.java differs, too.
> 
> **Needed adaptions:**
> 
> I had to resolve java/text/Format/DateFormat/TimeZoneNameTest.java.
> But the new version breaks the test. I assume this is because 21 does
> not have "[8174269](https://bugs.openjdk.org/browse/JDK-8174269): Remove COMPAT 
> locale data provider from JDK".
> The original version of the test passes.
> 
> test/jdk/sun/util/resources/TimeZone/Bug4848242.java is failing, too.
> The original version works, reverted.
> 
> Further I reverted test/jdk/java/util/TimeZone/TimeZoneData/aliases.txt and .../displaynames.txt
> as else java/util/TimeZone/Bug6329116.java (unmodified) starts failing.
> 
> See extra commits seperating out these edits.

I ran the `java/text/Format`, `java/util/TimeZone`, `sun/util/calendar` and `sun/util/resources` tests in four different scenarios:

* Build of 23u with its own tests -- all passed
* Build of 23u with the patches from this PR - failures from many tests, some untouched by this PR, due to changes post-21u
* Build of 21u with the patches from this PR - passed
* Build of 21u with the patches before the test reversion - three failures in `java/text/Format/DateFormat/TimeZoneNameTest.java`, `java/util/TimeZone/Bug6329116.java` and `sun/util/resources/TimeZone/Bug4848242.java`

In summary, this area has changed considerably due to changes in 22 & 23, notably [JDK-8174269](https://bugs.openjdk.org/browse/JDK-8174269) and [JDK-8317979](https://bugs.openjdk.org/browse/JDK-8317979).  `TimeZoneNameTest.java` and `Bug6329116.java` are run with the `COMPAT` provider in 21u, which is removed by 8174269. The CLDR provider is using zone names from tzdata (JDK-8317979) while, I believe, COMPAT has its own set of names which are unaffected by the tzdata change.

I thus think most of the reversion is correct. There is one exception:
~~~
Link	Asia/Ulaanbaatar	Asia/Choibalsan
~~~

This is a change in the timezone data for 2024b; see "Asia/Choibalsan is now an alias for Asia/Ulaanbaatar rather than being a separate Zone with differing behavior before April 2008. This seems better given our wildly conflicting information about Mongolia's time zone history. (Thanks to Heitor David Pinto.)" from the tzdata release notes. So this change should be reinstated, but the ones related to the three-letter zone names are correct.

Looking at this, but it will take a bit of time to work out what is going on with the tests.

The `ZoneId` change would affect every JDK that has `java.time.ZoneId` i.e. 8 and later. I think you might be confusing 8+ with just 8 alone. `ZoneId` defines `EST`, `MST` and `HST` as fixed offsets but the latest tzdata does not, instead making them links to `continent/city`-style timezones. In 24, they are changed to these new values in `ZoneId` but that requires a spec change that is not being backported to 23 and older. 

The [tz2024b_overridden_zones](https://github.com/openjdk/jdk23u/pull/191/files#diff-34c2e2f13c31af3c514eab2db322bb4192f4b2d6d888b4517e9f4be4fe4cbd3e) file brings back these fixed offsets. It does make me wonder if the 23u version of the tests were run against a tzdata with these fixed timezones back in play, as, for 21u, you seem to have ended up reverting the change which converts them from names to aliases. I'll try and dig into them further next week.

-------------

PR Review: https://git.openjdk.org/jdk21u-dev/pull/1143#pullrequestreview-2440030181
PR Comment: https://git.openjdk.org/jdk21u-dev/pull/1143#issuecomment-2465975263