On Fri, 23 Oct 2026 18:37:03 GMT, Naoto Sato <[email protected]> wrote:
>> This PR upgrades the CLDR to version 49. A corresponding CSR has also been >> drafted. Besides the data update itself, the JDK changes are briefly >> described below: >> >> - Support metazone name aliases in the CLDR converter, including aliases for >> specific name slots >> - Derive the localized GMT zero format from `gmtFormat`, following the >> removal of `gmtZeroFormat` >> - Update time zone parsing to handle localized GMT prefixes and names with a >> trailing GMT marker >> - Accept the plural operand `c` as a synonym for `e` in `CompactNumberFormat` >> - Remove Windows time zone mapping overrides now included in the CLDR >> - Update affected tests, CLDR version and terminology references, including >> the new CLDR backronym, and license notices. >> >> --------- >> - [x] I confirm that I make this contribution in accordance with the >> [OpenJDK Interim AI Policy](https://openjdk.org/legal/ai). > > Naoto Sato has updated the pull request incrementally with one additional > commit since the last revision: > > Copyright year update make/jdk/src/classes/build/tools/cldrconverter/Bundle.java line 1: > 1: /* I think some brief comments for the new methods added in `Bundle` and LDMLParseHandler` would make some of what is happening easier to follow. make/jdk/src/classes/build/tools/cldrconverter/CLDRConverter.java line 679: > 677: EnumSet<ZoneNameSlot> slots) { > 678: MetazoneNameAlias previous = > metazoneNameAliases.putIfAbsent(sourceKey, > 679: new MetazoneNameAlias(targetKey, slots)); You could defer creation of the record until it is confirmed that the source key is absent to avoid copying the `slots` for the cases when it already exists. src/java.base/share/classes/java/text/DecimalFormat.java line 1: > 1: /* Maybe did not show up because of the line break or the `<em>` but DFSProvider also needs the "Unicode Locale Data Markup Language (LDML)" wording update. src/java.base/share/classes/java/text/SimpleDateFormat.java line 2225: > 2223: && text.regionMatches(true, start, GMT, > 0, GMT.length())) { > 2224: gmtText = GMT; > 2225: } else if (upperC == > Character.toUpperCase(gmtZero.charAt(0)) I don't believe there are any tests added to confirm the localized gmt format handling. If that is the case, can we add one? src/java.base/share/classes/java/text/SimpleDateFormat.java line 2228: > 2226: && (text.length() - start) > > gmtZero.length() > 2227: && text.regionMatches(true, start, > gmtZero, 0, gmtZero.length()) > 2228: && (text.charAt(start + > gmtZero.length()) == '+' || text.charAt(start + gmtZero.length()) == '-')) { If this text is localized won't the '+' and '-' be localized as well? I guess that is a limitation, since the existing code below does not handle that as well. Also, is it not possible that the sign would precede the localized gmt text? src/java.base/share/classes/sun/util/locale/provider/TimeZoneNameUtility.java line 207: > 205: var rb = > ca.getLocaleResources(locale).getJavaTimeFormatData(); > 206: if (rb.containsKey("timezone.gmtZeroFormat")) { > 207: return rb.getString("timezone.gmtZeroFormat"); If `gmtZeroFormat` no longer exists in v49 is there a reason to bother querying it? If not, can we remove it, if so, can we make that clear (since the method doc says it is removed). test/jdk/java/time/test/java/time/format/TestZoneTextPrinterParser.java line 234: > 232: public void test_ParseText_GmtSuffix() { > 233: DateTimeFormatter formatter = > getFormatter(Locale.forLanguageTag("pt-BR"), TextStyle.FULL); > 234: assertDoesNotThrow(() -> formatter.parse("-01:00 GMT", > TemporalQueries.zone())); Instead of `assertDoesNotThrow` should we verify the value of the zone as well similar to below? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/33522#discussion_r4365060020 PR Review Comment: https://git.openjdk.org/jdk/pull/33522#discussion_r4364989129 PR Review Comment: https://git.openjdk.org/jdk/pull/33522#discussion_r4364095774 PR Review Comment: https://git.openjdk.org/jdk/pull/33522#discussion_r4363996698 PR Review Comment: https://git.openjdk.org/jdk/pull/33522#discussion_r4364017642 PR Review Comment: https://git.openjdk.org/jdk/pull/33522#discussion_r4364232618 PR Review Comment: https://git.openjdk.org/jdk/pull/33522#discussion_r4364422271
