New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
8296715: CLDR v42 update for tzdata 2022f #27
Conversation
👋 Welcome back andrew! A progress list of the required criteria for merging this PR into |
This backport pull request has now been updated with issue from the original commit. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good.
@gnu-andrew This change now passes all automated pre-integration checks. After integration, the commit message for the final commit will be:
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 ➡️ To integrate this PR with the above commit message to the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK.
Thanks both. Flagged with |
I see /integrate |
Going to push as commit 518047d. |
@gnu-andrew Pushed as commit 518047d. 💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored. |
This is a minimal backport of the CLDR v42 update for tzdata 2022f, just containing the timezone changes. The previous definition for
America/Chihuahua
, which is superseded by the change toAmerica_Central
on 2022-10-30, is retained asAmerica_Mountain
asMexico_Pacific
doesn't exist in 8u's version of CLDR and the change here is to define an end to that metazone, not alter it.The other changes are omitted as follows:
es_419.xml
in 8u's CLDR does not contain the patterns being altered.LocaleData.cldr
does not exist in 8uLocaleDataTest.java
does not need updating as the test has not been changed, as there is no data file change (LocaleData.cldr
)Regarding the latter two, the CLDR checks in the test were introduced as part of JDK-8008577: "Use CLDR Locale Data by Default". We obviously don't want to backport that in full, but updating LocaleDataTest.java with a CLDR data set would be useful.
However, I think it's out of scope for a rampdown time critical data fix like this, as it is likely a lengthy effort to get a passing data set, needing further CLDR updates. It should be handled separately. I'll open a bug and PR for this against 8u-dev.
Progress
Issue
Reviewers
Reviewing
Using
git
Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk8u pull/27/head:pull/27
$ git checkout pull/27
Update a local copy of the PR:
$ git checkout pull/27
$ git pull https://git.openjdk.org/jdk8u pull/27/head
Using Skara CLI tools
Checkout this PR locally:
$ git pr checkout 27
View PR using the GUI difftool:
$ git pr show -t 27
Using diff file
Download this PR as a diff file:
https://git.openjdk.org/jdk8u/pull/27.diff