8352716: (tz) Update Timezone Data to 2025b

[satyenme]

Backport of tzdata2025b. Nearly clean, but contains zone.tab file, which was removed by JDK-8166983.

Reverted change to test/jdk/java/util/TimeZone/TimeZoneData/aliases.txt and .../displaynames.txt when running make in test/jdk/java/util/TimeZone/tools/share to avoid the java/util/TimeZone/Bug6329116.java test failing, just as was done previously for 2024b.

Passed tier1 tests and make run-test TEST="jdk/java/util/TimeZone jdk/java/time/test jdk/sun/util/resources jdk/sun/text/resources jdk/sun/util/calendar" locally, GHA sanity tests.

---

Progress

• Change must be properly reviewed (1 review required, with at least 1 Reviewer)
• Change must not contain extraneous whitespace
• Commit message must refer to an issue
• JDK-8352716 needs maintainer approval

Issue

• JDK-8352716: (tz) Update Timezone Data to 2025b (Enhancement - P3 - Approved)

Reviewers

• Sergey Bylokhov (@mrserb - Reviewer)
• Andrew John Hughes (@gnu-andrew - Reviewer)

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk21u-dev.git pull/1557/head:pull/1557
$ git checkout pull/1557

Update a local copy of the PR:
$ git checkout pull/1557
$ git pull https://git.openjdk.org/jdk21u-dev.git pull/1557/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 1557

View PR using the GUI difftool:
$ git pr show -t 1557

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk21u-dev/pull/1557.diff

Using Webrev

Link to Webrev Comment

[bridgekeeper]

👋 Welcome back ssubramaniam! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

[openjdk]

@satyenme This change now passes all automated pre-integration checks.

ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details.

After integration, the commit message for the final commit will be:

8352716: (tz) Update Timezone Data to 2025b

Reviewed-by: serb, andrew

You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed.

At the time when this comment was updated there had been 46 new commits pushed to the master branch:

• 996f945: 8211400: nsk.share.gc.Memory::getArrayLength returns wrong value
• d2be3b7: 8347995: Race condition in jdk/java/net/httpclient/offline/FixedResponseHttpClient.java
• 4b5ca21: 8345133: Test sun/security/tools/jarsigner/TsacertOptionTest.java failed: Warning found in stdout
• e8daf0c: 8344361: Restore null return for invalid services from legacy providers
• ff0aa06: 8339300: CollectorPolicy.young_scaled_initial_ergo_vm gtest fails on ppc64 based platforms
• 7c45ed3: 8346049: jdk/test/lib/security/timestamp/TsaServer.java warnings
• 5f5e6e5: 8345357: test/jdk/javax/swing/JRadioButton/8033699/bug8033699.java fails in ubuntu22.04
• 41fe4e2: 8340978: Open source few DnD tests - Set6
• 2510358: 8341378: Open source few TrayIcon tests - Set8
• ec7d359: 8340967: Open source few Cursor tests - Set2
• ... and 36 more: https://git.openjdk.org/jdk21u-dev/compare/89b614d99790efe07b2fb31c33fe5560d3dc2850...master

As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details.

As you do not have Committer status in this project an existing Committer must agree to sponsor your change. Possible candidates are the reviewers of this PR (@mrserb, @gnu-andrew) but any other Committer may sponsor as well.

➡️ To flag this PR as ready for integration with the above commit message, type /integrate in a new comment. (Afterwards, your sponsor types /sponsor in a new comment to perform the integration).

[openjdk]

This backport pull request has now been updated with issue from the original commit.

[mlbridge]

Webrevs

• 00: Full (b3622710)

[openjdk]

⚠️ @satyenme This change is now ready for you to apply for maintainer approval. This can be done directly in each associated issue or by using the /approval command.

[satyenme]

/approval request for backport of 2025b tzdata. Nearly clean, but needed to re-add zone.tab file, which was removed by JDK-8166983.

Risk: Medium to Low. Tier 1 and relevant tz tests passing, as well as GHA sanity check tests. Backporting tzdata changes is a common enough procedure that, after review, we can be reasonably confident will work as intended.

Testing:

• GHA Sanity Checks
• Tier 1 tests locally
• make run-test TEST="jdk/java/util/TimeZone jdk/java/time/test jdk/sun/util/resources jdk/sun/text/resources jdk/sun/util/calendar"

[openjdk]

@satyenme
8352716: The approval request has been created successfully.

[GoeLin]

Hi @satyenme
Thanks for backporting this.
Could you please first backport to 24?

[satyenme]

I'm seeing this request for 24: openjdk/jdk24u#161. To avoid duplication, I'll wait for further action there

[gnu-andrew]

I'm seeing this request for 24: openjdk/jdk24u#161. To avoid duplication, I'll wait for further action there

Yes, I'm already handling the 24u update. I'm not sure of the rush here. I was planning to handle further backports as each was integrated. Attempting to do them in parallel risks extra work if changes come up in review.

[gnu-andrew]

Matches my patch for 24u (openjdk/jdk24u#161) and testing looks good. I'll look over the ones for 8u, 11u & 17u tomorrow.

[GoeLin]

Hi @satyenme, @gnu-andrew
Well, there is no rush. But it is common practice to do younger releases first, thus I will only approve 21 after 24 got approved. And if you label for approval knowing there is a blocker, it spams the approval filter which us approvers check regularly. Thus I ususally point to the reason for the block the first time I check a change, and remove the label if I encounter a blocked backport in the filter a second time.

[gnu-andrew]

Hi @satyenme, @gnu-andrew Well, there is no rush. But it is common practice to do younger releases first, thus I will only approve 21 after 24 got approved. And if you label for approval knowing there is a blocker, it spams the approval filter which us approvers check regularly. Thus I ususally point to the reason for the block the first time I check a change, and remove the label if I encounter a blocked backport in the filter a second time.

I just pushed 24u so this should be good for approval now. I'd appreciate a bit of time today to review 8u, 11u & 17u before those go in though.

[satyenme]

/integrate

Edit: missed that the label was removed.

[openjdk]

@satyenme This pull request has not yet been marked as ready for integration.

[satyenme]

/integrate

[openjdk]

@satyenme
Your change (at version b362271) is now ready to be sponsored by a Committer.

[phohensee]

/sponsor

[openjdk]

Going to push as commit 27f3ab6.
Since your change was applied there have been 47 commits pushed to the master branch:

• 6cd096e: 8328864: NullPointerException in sun.security.jca.ProviderList.getService()
• 996f945: 8211400: nsk.share.gc.Memory::getArrayLength returns wrong value
• d2be3b7: 8347995: Race condition in jdk/java/net/httpclient/offline/FixedResponseHttpClient.java
• 4b5ca21: 8345133: Test sun/security/tools/jarsigner/TsacertOptionTest.java failed: Warning found in stdout
• e8daf0c: 8344361: Restore null return for invalid services from legacy providers
• ff0aa06: 8339300: CollectorPolicy.young_scaled_initial_ergo_vm gtest fails on ppc64 based platforms
• 7c45ed3: 8346049: jdk/test/lib/security/timestamp/TsaServer.java warnings
• 5f5e6e5: 8345357: test/jdk/javax/swing/JRadioButton/8033699/bug8033699.java fails in ubuntu22.04
• 41fe4e2: 8340978: Open source few DnD tests - Set6
• 2510358: 8341378: Open source few TrayIcon tests - Set8
• ... and 37 more: https://git.openjdk.org/jdk21u-dev/compare/89b614d99790efe07b2fb31c33fe5560d3dc2850...master

Your commit was automatically rebased without conflicts.

[openjdk]

@phohensee @satyenme Pushed as commit 27f3ab6.

💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored.