-
Enhancement
-
Resolution: Fixed
-
P2
-
11, 13, 14
-
b08
-
generic
-
generic
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8231833 | 13.0.2 | Ramanand Patil | P2 | Resolved | Fixed | b02 |
JDK-8231846 | 11.0.6-oracle | Ramanand Patil | P2 | Closed | Fixed | b01 |
JDK-8231517 | 11.0.6 | Naoto Sato | P2 | Resolved | Fixed | b01 |
JDK-8231298 | 11.0.5 | Naoto Sato | P2 | Resolved | Fixed | b09 |
JDK-8303144 | 8u381 | Yoshiki Sato | P2 | Closed | Fixed | b01 |
JDK-8307434 | 8u371 | Ryan Wallace | P2 | Resolved | Fixed | b32 |
JDK relies on the time zone data from IANA time zone database. [1] Since last year, they have implemented *negative* save time, e.g., minus one hour in winter from the standard time in summer in Ireland. Another change was the transition time beyond a day period. Example for this is the historic DST in Tokyo, where the transition starts from Saturday 25:00 (which should be translated into the next day (Sunday) at 1am). These changes were disruptive to the JDK, since the implementation never expected the DST to have a negative value, nor transition time beyond a day.
For such changes to be sunk in, IANA has been providing three formats for the time being, i.e., vanguard/main/rearguard, where vanguard/main contains those changes, while rearguard remains as before, by translating negative savings into positive. However, their latest release, tzdata2019b, stopped providing the rearguard format which JDK has been using for the said reason.
Changes:
- In order to support the negative DST, JDK's parser needs to be modified to recognize the vanguard format. The parser looks into the "Zone" and "Rule" entries, and if it finds the negative savings either in the "fixed" saving in the Zone, or a Rule, then it adjusts the standard offset in the Zone and savings in the Rule by that negative amount, so that the compiled time zone data contains only the positive savings. This translation is needed in order for the TZUpdater to use the output "tzdb.dat" file for the previously released JDKs.
- Transition cutover time beyond 24:00 will be adjusted to fit in 0:00-24:00 by adjusting the transition date.
- In the discussion occurred on core-libs mailing list before [2], API enhancements were suggested, but not doing so by taking the backward compatibility into consideration.
[1] https://www.iana.org/time-zones
[2] http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-October/056167.html
- backported by
-
JDK-8231298 TZ database in "vanguard" format support
- Resolved
-
JDK-8231517 TZ database in "vanguard" format support
- Resolved
-
JDK-8231833 TZ database in "vanguard" format support
- Resolved
-
JDK-8307434 TZ database in "vanguard" format support
- Resolved
-
JDK-8231846 TZ database in "vanguard" format support
- Closed
-
JDK-8303144 TZ database in "vanguard" format support
- Closed
- blocks
-
JDK-8212684 TZupdater 2.2.0 not able to update with tzdata2018f release
- Closed
- csr for
-
JDK-8226601 TZ database in "vanguard" format support
- Closed
- duplicates
-
JDK-8195595 Negative daylight saving time breaks tzdata handling
- Closed
-
JDK-8223388 TestZoneInfo310.java fails post tzdata2018i integration
- Closed
-
JDK-8259782 Vanguard tzdata support for JDK8u/7u
- Closed
- relates to
-
JDK-8212684 TZupdater 2.2.0 not able to update with tzdata2018f release
- Closed
-
JDK-8230554 TZUpdater support for "vanguard" format (JSR-310 part only)
- Resolved
-
JDK-8166983 Remove old/legacy unused tzdata files
- Resolved
-
JDK-8213393 Clean up copyright headers in test/jdk/sun/util/calendar/zi/tzdata
- Resolved
-
JDK-8274864 Remove Amman/Cairo hacks in ZoneInfoFile
- Resolved
-
JDK-8259782 Vanguard tzdata support for JDK8u/7u
- Closed
-
JDK-8300097 Possibly wrong DST rules in Europe/Dublin and Africa/Casablanca
- Closed
-
JDK-8213016 (tz) Upgrade time-zone data to tzdata2018f
- Closed