On Thu, 6 Aug 2026 17:25:10 GMT, Oumaiyma Intissar <[email protected]> wrote:
> This updates the JDK time zone data from `tzdata2026b` to `tzdata2026c`. > > The main tzdata changes included here are: > > - Morocco moves back to permanent UTC on 2026-09-20, removing future > projected Ramadan negative-DST rules. > - Alberta moves to permanent UTC-06, modeled with the traditional `CST` > abbreviation after the temporary CLDR workaround period. > - British Columbia modeling/commentary is updated from the upstream 2026c > data. > - Leap second metadata is refreshed with the new expiration date. > - Related `TimeZoneData` test data is regenerated for `tzdata2026c`. > > The tests were adjusted where previous expectations depended on old tzdata > behavior or assumed tzdata abbreviations and localized CLDR names would > always match: > > - `NegativeDSTTest.java` and `TestZoneRules.java` no longer expect Morocco > negative-DST transitions after the 2026 move to permanent UTC. > - `Bug6329116.java` allows the known CLDR localized short-name mismatch for > Edmonton/Vancouver and their aliases. > - `TestZoneTextPrinterParser.java` restricts daylight-name expectations to > zones with explicit CLDR DST-offset metadata, avoiding a false `Mountain > Daylight Time` expectation for `America/Yellowknife`. > > All changed tests, plus tier1, tier2, and tier3 validation, passed. > > > --------- > - [x] I confirm that I make this contribution in accordance with the [OpenJDK > Interim AI Policy](https://openjdk.org/legal/ai). Overall looks fine to me. test/jdk/java/time/test/java/time/format/TestZoneTextPrinterParser.java line 74: > 72: "Canada/Pacific", ZoneOffset.of("-07:00"), > 73: "Europe/Dublin", ZoneOffset.of("+01:00"), > 74: "Eire", ZoneOffset.of("+01:00")); Since these are golden test data, I think hard-coding the explicit dst information is fine. However, I think it would be helpful to add a comment indicating the corresponding CLDR version for these data. Nit: I think `CLDR_EXPLICIT_DST_OFFSETS` would be a better field name. test/jdk/java/time/test/java/time/zone/TestZoneRules.java line 94: > 92: {WINDHOEK, LocalDate.of(2016, 9, 23), OFF_2, OFF_1, true}, > 93: > 94: // Africa/Casablanca for the Rule "Morocco" I'd prefer changing the comment to "Defines negative DST until early 2026, and permanent DST later that year, starting with 2026c". Also I'd leave one test case for the year 2038 (previously the last one). test/jdk/java/util/TimeZone/Bug6329116.java line 50: > 48: "America/Yellowknife", "MST", > 49: "America/Vancouver", "PST", > 50: "Canada/Pacific", "PST"); Let's add a comment mentioning that, as of CLDR v48.2, CLDR provides short names for these zones with explicit DST offsets. test/jdk/java/util/TimeZone/Bug6329116.java line 262: > 260: > 261: // Some zones use CLDR short names even when the tzdata FORMAT > changed. > 262: if (locale.equals(Locale.US) && !inDST) { The test only verifies names in the US locale, so this locale check isn't needed. test/jdk/java/util/TimeZone/NegativeDSTTest.java line 87: > 85: {CASABLANCA, LocalDate.of(2038, 11, 1), ONE_HOUR, true}, > 86: {CASABLANCA, LocalDate.of(2087, 3, 31), 0, false}, > 87: {CASABLANCA, LocalDate.of(2087, 5, 12), ONE_HOUR, true}, Same comment as in TestZoneRules applies here ------------- PR Review: https://git.openjdk.org/jdk/pull/32240#pullrequestreview-4878010812 PR Review Comment: https://git.openjdk.org/jdk/pull/32240#discussion_r3731706294 PR Review Comment: https://git.openjdk.org/jdk/pull/32240#discussion_r3731789308 PR Review Comment: https://git.openjdk.org/jdk/pull/32240#discussion_r3731871416 PR Review Comment: https://git.openjdk.org/jdk/pull/32240#discussion_r3731921570 PR Review Comment: https://git.openjdk.org/jdk/pull/32240#discussion_r3731930147
