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

[Goetz Lindenmaier]

On Sat, 9 Nov 2024 01:37:16 GMT, Andrew John Hughes <andrew 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.
>
> 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.

Hi @gnu-andrew, I just missed adding tz2024b_overridden_zones to the PR, but it was there when I ran all the tests in my local dir.  
Our nighttests are green except for TestZoneInfo310.java which could not find above file.

Hi @gnu-andrew 
you mean I should add the link back to aliases.txt?  I pushed another commit doing so.
Bug6329116 still passes.
Thanks for looking at this!

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

PR Comment: https://git.openjdk.org/jdk21u-dev/pull/1143#issuecomment-2466423955
PR Comment: https://git.openjdk.org/jdk21u-dev/pull/1143#issuecomment-2486370460