8352097: (tz) zone.tab update missed in 2025a backport

[gnu-andrew]

As with 21u, the 17u backport of the tzdata 2025a update missed an update to zone.tab, as this was not present in the 25u commit on which it was originally based, due to its removal in JDK-8166983. The change was in the 24u commit which was applied later than the 21u one.

We should add this missing change to the existing 2025a update in 17.0.15 and consider backporting JDK-8166983 for 17.0.16 (now proposed for 24u).

Backport from 21u is clean. Tests pass:

==============================
Test summary
==============================
   TEST                                              TOTAL  PASS  FAIL ERROR   
   jtreg:test/jdk/java/text/Format                     111   111     0     0   
   jtreg:test/jdk/java/util/TimeZone                    25    25     0     0   
   jtreg:test/jdk/sun/util/calendar                      5     5     0     0   
   jtreg:test/jdk/sun/util/resources                    22    22     0     0   
   jtreg:test/jdk/java/time                            186   186     0     0   
==============================
TEST SUCCESS

---

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-8352097 needs maintainer approval

Issue

• JDK-8352097: (tz) zone.tab update missed in 2025a backport (Bug - P4 - Approved)

Reviewers

• Severin Gehwolf (@jerboaa - Reviewer)
• Sergey Bylokhov (@mrserb - Reviewer)

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk17u.git pull/405/head:pull/405
$ git checkout pull/405

Update a local copy of the PR:
$ git checkout pull/405
$ git pull https://git.openjdk.org/jdk17u.git pull/405/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 405

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

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk17u/pull/405.diff

Using Webrev

Link to Webrev Comment

[bridgekeeper]

👋 Welcome back andrew! 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]

@gnu-andrew 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:

8352097: (tz) zone.tab update missed in 2025a backport

Reviewed-by: sgehwolf, serb

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 no new commits pushed to the master branch. If another commit should be pushed before you perform the /integrate command, your PR will be automatically rebased. If you prefer to avoid any potential automatic rebasing, please check the documentation for the /integrate command for further details.

➡️ To integrate this PR with the above commit message to the master branch, type /integrate in a new comment.

[openjdk]

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

[mlbridge]

Webrevs

• 00: Full (8c6f1d9f)

[GoeLin]

This is identical to the backport to 21.
The edited file lives in a different directory, therefore this is not a clean backport.
I second that this goes to jdk17u.

[jerboaa]

JDK 21 file path is src/java.base/share/data/tzdata/zone.tab
JDK 17 file path is make/data/tzdata/zone.tab

Change to the file itself is the same. Looks good.

[openjdk]

⚠️ @gnu-andrew 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.

[gnu-andrew]

This is identical to the backport to 21. The edited file lives in a different directory, therefore this is not a clean backport. I second that this goes to jdk17u.

git cherry-pick handled the file movement automatically so I would regard this as clean, much as I would regard automated path shuffling from 11u to 8u as clean. No manual intervention was required and there are no differences in the body of the diff.

[gnu-andrew]

/approval request Follow-up fix to the tzdata 2025a backport to include a change to a file no longer present in OpenJDK 25, but patched in OpenJDK 24. Tests on java/text/Format, java/util/TimeZone, sun/util/calendar, sun/util/resources & java/time all pass.

[openjdk]

@gnu-andrew
8352097: The approval request has been created successfully.

[GoeLin]

This is identical to the backport to 21. The edited file lives in a different directory, therefore this is not a clean backport. I second that this goes to jdk17u.

git cherry-pick handled the file movement automatically so I would regard this as clean, much as I would regard automated path shuffling from 11u to 8u as clean. No manual intervention was required and there are no differences in the body of the diff.

Thanks for giving this additional information. The fact that you could created this automatically reduces the chance for error. But this context is needed to make the information useful for a reviewer.
Also, as approver, I usually take a different look if I know no reveiwer was involved. And as backporter to a later release, I would like information about the previous backports. In both cases, and similar with the 24u backport of the timezone change, it is helpful if a change like this is not labeled as "clean".
Btw, would skara handle the file path differnces? I just did the backport of JDK-8303770, which has the same path issue but the test needs to be resolved.
I know there are backports that succeed with the /backport command and are not recognized clean, and vice versa.

[gnu-andrew]

This is identical to the backport to 21. The edited file lives in a different directory, therefore this is not a clean backport. I second that this goes to jdk17u.

git cherry-pick handled the file movement automatically so I would regard this as clean, much as I would regard automated path shuffling from 11u to 8u as clean. No manual intervention was required and there are no differences in the body of the diff.

Thanks for giving this additional information. The fact that you could created this automatically reduces the chance for error. But this context is needed to make the information useful for a reviewer. Also, as approver, I usually take a different look if I know no reviewer was involved. And as backporter to a later release, I would like information about the previous backports. In both cases, and similar with the 24u backport of the timezone change, it is helpful if a change like this is not labeled as "clean".

It's not labelled 'clean' :) I have issues with that label myself. I don't agree with a 'clean' determination being sufficient reason to not review a patch. It's why I made a point of reviewing your LCMS patches. A patch can easily be 'clean' by simply adding a completely new file that then breaks the build. It's reassuring to hear that you are wary of such changes as well.

I've used the term 'clean' long before we were working on GitHub to mean what I wrote above, and only what I wrote above; that it applied without manual intervention. I don't intend it to mean the patch does not need review and I'll try to be more explicit on this in future.

I hadn't actually realised that this one had auto-path-shuffled because it did so completely silently and - most importantly - the build & testing went fine. Now I think about it, I have seen this happen with other recent tzdata updates too.

Btw, would skara handle the file path differnces? I just did the backport of JDK-8303770, which has the same path issue but the test needs to be resolved. I know there are backports that succeed with the /backport command and are not recognized clean, and vice versa.

I haven't tried /backport with this one, but I am aware that it has some fuzzy logic that can e.g. handle copyright header differences.

[gnu-andrew]

/integrate

[openjdk]

Going to push as commit 305512c.

[openjdk]

@gnu-andrew Pushed as commit 305512c.

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