On Fri, 13 Sep 2024 18:39:42 GMT, Naoto Sato <na...@openjdk.org> wrote:
>> Yet another preparation for upgrading the time zone data to 2024b, which
>> introduced a new abbreviation format "%z". The update includes:
>> ...
>> The main source files' time zone abbreviations now use %z,
>> supported by zic since release 2015f and used in vanguard form
>> since release 2022b. For example, America/Sao_Paulo now contains
>> the zone continuation line "-3:00 Brazil %z", which is less error
>> prone than the old "-3:00 Brazil -03/-02". This does not change
>> the represented data: the generated TZif files are unchanged.
>> Rearguard form still avoids %z, to support obsolescent parsers.
>> ...
>>
>> Also fixed the logic to retrieve the linked tz name that is chaining.
>
> Naoto Sato has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Do not add all links
IIUC we treat the %z _FORMAT_ the same as the numeric offset _FORMAT_, that is
we rely on the _STDOFF_ to calculate the GMT format during runtime.
The changes in `convertGMTName(String f)` seem to accomplish that.
src/java.base/share/classes/sun/util/cldr/CLDRTimeZoneNameProviderImpl.java
line 270:
> 268: ResourceBundle fd = lr.getJavaTimeFormatData();
> 269: var zi = ZoneInfoFile.getZoneInfo(id);
> 270: if (zi == null) {
This is an added fallback, and is not related to the "%z" logic right?
-------------
Marked as reviewed by jlu (Committer).
PR Review: https://git.openjdk.org/jdk/pull/20979#pullrequestreview-2304414315
PR Review Comment: https://git.openjdk.org/jdk/pull/20979#discussion_r1759703352
