JDK-8340138 : (tz) Update Timezone Data to 2024b
  • Type: CSR
  • Component: core-libs
  • Sub-Component: java.time
  • Priority: P3
  • Status: Closed
  • Resolution: Approved
  • Fix Versions: 24
  • Submitted: 2024-09-13
  • Updated: 2024-09-28
  • Resolved: 2024-09-28
Related Reports
CSR :  
Description
Summary
-------

Updating the TZ Data Base to 2024b

Problem
-------
The update to 2024b included:
```
     Names present only for compatibility with UNIX System V
     (last released in the 1990s) have been moved to 'backward'.
     These names, which for post-1970 timestamps mostly just duplicate
     data of geographical names, were confusing downstream uses.
```
This includes changes to "EST", "MST", and "HST", i.e., changing those time zones from distinct time zones to links to other time zones. Problem here is, previously they are defined as fixed offset zones, e.g., "EST" is "-05:00" without any DST transitions. With 2024b, "EST" is now a link to "America/Panama." As in the above quote, "America/Panama" has not observed DST since 1970, but offset did change before (i.e., not equal to fixed "-05:00").

In `java.time.ZoneId.SHORT_IDS` field, they are explictly defined as fixed zones, which should be amended.

Solution
--------

Modify the mappings in `ZoneId` class. Parsing of the short zone names "EST", "MST", and "HST" is not affected by this change. Also, explictly mention that the mapping may change with the future TZDB updates.

Specification
-------------
Change the description for `java.time.ZoneId.SHORT_IDS` field as:

```
--- a/src/java.base/share/classes/java/time/ZoneId.java
+++ b/src/java.base/share/classes/java/time/ZoneId.java
@@ -186,15 +186,12 @@
      * This map allows the IDs to continue to be used via the
      * {@link #of(String, Map)} factory method.
      * <p>
-     * This map contains a mapping of the IDs that is in line with TZDB 2005r and
+     * This map contains a mapping of the IDs that is in line with TZDB 2024b and
      * later, where 'EST', 'MST' and 'HST' map to IDs which do not include daylight
-     * savings.
+     * savings since 1970. This mapping may change in update releases in support of new versions of TZDB .
      * <p>
      * This maps as follows:
      * <ul>
-     * <li>EST - -05:00</li>
-     * <li>HST - -10:00</li>
-     * <li>MST - -07:00</li>
      * <li>ACT - Australia/Darwin</li>
      * <li>AET - Australia/Sydney</li>
      * <li>AGT - America/Argentina/Buenos_Aires</li>
@@ -208,10 +205,13 @@
      * <li>CTT - Asia/Shanghai</li>
      * <li>EAT - Africa/Addis_Ababa</li>
      * <li>ECT - Europe/Paris</li>
+     * <li>EST - America/Panama</li>
+     * <li>HST - Pacific/Honolulu</li>
      * <li>IET - America/Indiana/Indianapolis</li>
      * <li>IST - Asia/Kolkata</li>
      * <li>JST - Asia/Tokyo</li>
      * <li>MIT - Pacific/Apia</li>
+     * <li>MST - America/Phoenix</li>
      * <li>NET - Asia/Yerevan</li>
      * <li>NST - Pacific/Auckland</li>
      * <li>PLT - Asia/Karachi</li>
```



Comments
[~naoto], I Approved an amended version of the future flexibility clause. If something else is more appropriate, please re-Finalized the CSR and I'll take another look.
28-09-2024

Moving to Approved for JDK 24 only. If not done so already, please consider if a release note is warranted.
26-09-2024

Excluded backports to LTSes from this CSR for now.
24-09-2024

Generally, what we done for similar areas over time, where an API in the JDK is tracking some kind of external standard which can have a lifecycle independent of the JDK, is to build-in enough flexibility in the specification to accommodate the sort of anticipated changes that might occur in the specification.
23-09-2024

[~darcy], what are the options here for prior LTSes? Backporting tzdata2024b automatically introduces spec violation, so :- - Wait for the next MRs to backport - Make special changes to backports - Backport as it is, expecting the spec violation. Please note that we also need to consider tzupdater tool, which can update tzdata separate from JDK.
21-09-2024

Moving to Provisional, not Approved. The spec changes in `ZoneId` would seem to be out of bounds for the update releases.
20-09-2024