On Tue, 15 Sep 2026 21:27:21 GMT, Min Choi <[email protected]> wrote: > This updates the JDK time zone data from `tzdata2026c` to `tzdata2026d`. > > The main tzdata changes included here are: > > - Canada's Northwest Territories moves to permanent UTC-06. This affects > `America/Inuvik` and is modeled with the traditional `CST` abbreviation. > - Colombia's 1992 spring-forward date is corrected to May 2 at 00:00. > - Iran's 1979 spring-forward date is corrected to May 26 at 00:00. > - `EST5EDT`, `CST6CDT`, `MST7MDT`, and `PST8PDT` are changed from links to > standalone backward-compatibility zones that conform to POSIX better. > - Related `TimeZoneData` test data is regenerated for `tzdata2026d`. > > `Bug6329116.java` needed to be updated to accept CLDR's existing `MST` short > name for `America/Inuvik`. > It follows the same approach as > https://github.com/openjdk/jdk/pull/32240/changes#diff-2f3a55c8a143b7a86acdb3796900f0956422623166b93ec2c5f7f357a8197d72R45-R51. > > > `make images` and the affected timezone, `java.time`, resource, > text-resource, and calendar tests passed. > tier1, 2, 3, testing passed as well. > > > ============================== > Test summary > ============================== > TEST TOTAL PASS FAIL ERROR > SKIP > jtreg:test/jdk/java/util/TimeZone 28 25 0 0 > 3 > jtreg:test/jdk/java/time/test 80 80 0 0 > 0 > jtreg:test/jdk/sun/util/resources 23 23 0 0 > 0 > jtreg:test/jdk/sun/text/resources 18 18 0 0 > 0 > jtreg:test/jdk/sun/util/calendar 3 3 0 0 > 0 > ============================== > TEST SUCCESS > > > I know that we just did 2026c import. But I think because this also affects > related Canada timezones, we should prioritize getting 2026d in as well for > October. > > After review, I plan to work the backports down into 27, 25, 21, 17 for now > since those are completed for 2026c. > > --------- > - [x] I confirm that I make this contribution in accordance with the [OpenJDK > Interim AI Policy](https://openjdk.org/legal/ai).
I'll have a closer look at this one later this evening, but @naotoj should take a look too. I think for trunk we can wait for the next CLDR update, but the update releases will need the `metaZones.xml` update from this PR as we did with JDK-8390388 & JDK-8390380 : https://github.com/unicode-org/cldr/pull/6136/changes#diff-db734c9cb2f8881b3f3506871ea8422259da8291896f1f82d2dcf6149ed16e92 We can handle that under a separate PR & bug as before. ------------- PR Comment: https://git.openjdk.org/jdk/pull/32892#issuecomment-5701927648
