8292579: (tz) Update Timezone Data to 2022c

[satoyoshiki]

Please review this PR. The PR adopts the official tzdata2022c as it is.
It means the pre-1970s data merged in tzdata2022c doesn't exist.
All tests have been passed with no failures.

---

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

Issue

• JDK-8292579: (tz) Update Timezone Data to 2022c

Reviewers

• Naoto Sato (@naotoj - Reviewer)
• Alan Bateman (@AlanBateman - Reviewer)

Reviewing

Using git

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

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

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 10012

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

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/10012.diff

[satoyoshiki]

/issue add JDK-8292579

[bridgekeeper]

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

@satoyoshiki The primary solved issue for a PR is set through the PR title. Since the current title does not contain an issue reference, it will now be updated.

[openjdk]

@satoyoshiki The following labels will be automatically applied to this pull request:

• core-libs
• i18n

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing lists. If you would like to change these labels, use the /label pull request command.

[satoyoshiki]

The test failure seems to be irrelevant to this fix.
Problem listed by JDK-8292498 and also mentioned as that the failure may occur on non-Windows platforms.

https://bugs.openjdk.org/browse/JDK-8292498?focusedCommentId=14518336&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14518336

[mlbridge]

Webrevs

• 00: Full (d58c91fb)

[naotoj]

LGTM

[openjdk]

@satoyoshiki 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:

8292579: (tz) Update Timezone Data to 2022c

Reviewed-by: naoto, alanb

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 16 new commits pushed to the master branch:

• a366e82: 7113208: Incorrect javadoc on java.net.DatagramPacket.setLength()
• ac05bc8: 8293293: Move archive heap loading code out of heapShared.cpp
• e1e6732: 8293319: [C2 cleanup] Remove unused other_path arg in Parse::adjust_map_after_if
• 5757e21: 8292385: assert(ctrl == kit.control()) failed: Control flow was added although the intrinsic bailed out
• 3993a1f: 8292067: Convert test/sun/management/jmxremote/bootstrap shell tests to java version
• 83a3408: 8293315: Add back logging for Placeholders
• b6477fd: 8293288: bootcycle build failure after JDK-8173605
• 0c6094e: 8293188: x86_64: Introduce stubGenerator_x86_64.hpp
• 2baeebb: 8293006: sun/tools/jhsdb/JStackStressTest.java fails with "UnalignedAddressException: 8baadbabe"
• da99e3e: 8289400: Improve com/sun/jdi/TestScaffold error reporting
• ... and 6 more: https://git.openjdk.org/jdk/compare/bc5ffc8e472ba7bbafbf68d19d1f06dd1cba10e1...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 (@naotoj, @AlanBateman) 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).

[satoyoshiki]

/integrate

[openjdk]

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

[naotoj]

/sponsor

[openjdk]

Going to push as commit 98d85e6.
Since your change was applied there have been 46 commits pushed to the master branch:

• 7c96608: 8293403: JfrResolution::on_jvmci_resolution crashes when caller is null
• c05015b: 8291736: find_method_handle_intrinsic leaks Method*
• b2067e6: 8291725: Leftover marks when VM shutdown aborts bitmap clearing make mixed gc fail
• 6a1e98c: 8293213: G1: Remove redundant assertion in G1RemSet::clean_card_before_refine
• a92c1ff: 8287912: GTK L&F : Background of tree icons are red
• 272745b: 8293340: Remove unused _code in {Zero,Template}InterpreterGenerator
• 26f2a97: 8290561: Coalesce incubator-module warnings for single-file source-code programs
• 8e22f2b: 8293361: GHA: dump config.log in case of configure failure
• b17758a: 8247283: Enable the new conformant preprocessor option in Visual Studio
• 1bed23a: 8293353: [BACKOUT] G1: Remove redundant is-marking-active checks in C1 barrier
• ... and 36 more: https://git.openjdk.org/jdk/compare/bc5ffc8e472ba7bbafbf68d19d1f06dd1cba10e1...master

Your commit was automatically rebased without conflicts.

[openjdk]

@naotoj @satoyoshiki Pushed as commit 98d85e6.

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

[gnu-andrew]

Should this not have included an update to the resource bundles - as with ad3be04 - so that Europe/Kyiv is recognised?

[gnu-andrew]

That is something we've patched locally e.g. https://src.fedoraproject.org/rpms/java-11-openjdk/pull-request/163 and we have a test which fails without and passes with, though it does use sun.util.resources directly.

[naotoj]

Names are retrieved through aliases, so I think there is no need to add extra names in the COMPAT resource bundles.

% ./build/macosx-aarch64/jdk/bin/jshell -R-Djava.locale.providers=COMPAT JAVASE
|  Welcome to JShell -- Version 20-internal
|  For an introduction type: /help intro

jshell> ZoneId.of("Europe/Kyiv").getDisplayName(TextStyle.FULL, Locale.US)
$178 ==> "Eastern European Time"

jshell> ZoneId.of("Europe/Kiev").getDisplayName(TextStyle.FULL, Locale.US)
$179 ==> "Eastern European Time"

jshell> ZoneId.of("Europe/Kyiv").getDisplayName(TextStyle.FULL, Locale.JAPAN)
$180 ==> "東部ヨーロッパ時間"

jshell> ZoneId.of("Europe/Kiev").getDisplayName(TextStyle.FULL, Locale.JAPAN)
$181 ==> "東部ヨーロッパ時間"

CLDR incorporated the Kyiv/Kiev aliasing in their upcoming version 42, JDK does not have the alias yet, thus:

%  ./build/macosx-aarch64/jdk/bin/jshell JAVASE                                 
|  Welcome to JShell -- Version 20-internal
|  For an introduction type: /help intro

jshell> ZoneId.of("Europe/Kyiv").getDisplayName(TextStyle.FULL, Locale.US)
$178 ==> "Kyiv Time"

jshell> ZoneId.of("Europe/Kiev").getDisplayName(TextStyle.FULL, Locale.US)
$179 ==> "Eastern European Time"

jshell> ZoneId.of("Europe/Kyiv").getDisplayName(TextStyle.FULL, Locale.JAPAN)
$180 ==> "Kyiv時間"

jshell> ZoneId.of("Europe/Kiev").getDisplayName(TextStyle.FULL, Locale.JAPAN)
$181 ==> "東ヨーロッパ時間"

jshell> ZoneId.of("Europe/Kiev").getDisplayName(TextStyle.FULL, Locale.JAPAN)

This will be fixed once we incorporate CLDR v42 into JDK repository. Since we don't backport CLDR, TZ backports should separately cherry-pick the changes in timezone.xml, such as:

diff --git a/make/data/cldr/common/bcp47/timezone.xml b/make/data/cldr/common/bcp47/timezone.xml
index f0812776d5d..ddbccff077c 100644
--- a/make/data/cldr/common/bcp47/timezone.xml
+++ b/make/data/cldr/common/bcp47/timezone.xml
@@ -394,7 +394,7 @@ For terms of use, see http://www.unicode.org/copyright.html
             <type name="tvfun" description="Funafuti, Tuvalu" alias="Pacific/Funafuti"/>
             <type name="twtpe" description="Taipei, Taiwan" alias="Asia/Taipei ROC"/>
             <type name="tzdar" description="Dar es Salaam, Tanzania" alias="Africa/Dar_es_Salaam"/>
-            <type name="uaiev" description="Kyiv, Ukraine" alias="Europe/Kiev"/>
+            <type name="uaiev" description="Kyiv, Ukraine" alias="Europe/Kiev Europe/Kyiv"/>
             <type name="uaozh" description="Zaporizhia (Zaporozhye), Ukraine" alias="Europe/Zaporozhye"/>
             <type name="uasip" description="Simferopol, Ukraine" alias="Europe/Simferopol"/>
             <type name="uauzh" description="Uzhhorod (Uzhgorod), Ukraine" alias="Europe/Uzhgorod"/>

[gnu-andrew]

Interesting, I remember changes like this causing failures in the past. Maybe they were introducing completely new zones. It looks good for the old java.util API as well:

$ ~/builder/trunk/images/jdk/bin/jshell -R-Djava.locale.providers=COMPAT JAVASE
|  Welcome to JShell -- Version 20-internal
|  For an introduction type: /help intro

jshell> ZoneId.of("Europe/Kyiv").getDisplayName(TextStyle.FULL, Locale.US)
$178 ==> "Eastern European Time"

jshell> TimeZone.getTimeZone("Europe/Kyiv").getDisplayName(false, TimeZone.LONG, Locale.US)
$179 ==> "Eastern European Time"

and similar for 11u & 17u with an updated tzdb. I guess we just need the CLDR change in a backport then.

[gnu-andrew]

I've opened https://bugs.openjdk.org/browse/JDK-8293834 for the CLDR backport and will open a PR tomorrow for 19u.