JDK-8212970 : TZ database in "vanguard" format support
  • Type: Enhancement
  • Component: core-libs
  • Sub-Component: java.time
  • Affected Version: 11,13,14
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2018-10-25
  • Updated: 2021-03-16
  • Resolved: 2019-07-26
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 11
Related Reports
Blocks :  
CSR :  
Duplicate :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  

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.


- 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
After looking into the backport of this, and some discussion with Martin Buchholz [0], I've decided this isn't worth the risk for OpenJDK 8u. The patch is basically a rewrite for 8u, and would end up effectively doing the current translation at JDK build time that can be easily done using the scripts in the tzdata package before importing the new data. Should upstream support for conversion be dropped due to some additional change, we may have to revisit this decision. [0] https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-June/011931.html

Fix Request (13u) This fix is required for similar reasons as 11u. It will ease backport of tzdata2019c(JDK-8231098) and future timezone updates. The patch was not applied cleanly hence review is done at: https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-September/001934.html The fix has low risk and has passed all the related testing including JCK.

Fix request (11u) Requesting backport of this fix to JDK11 updates to ease backport of required timezone update JDK-8228469 (tzdata2019b) and further timezone updates. The patch did not apply and hence a review discussion was started: https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-September/001895.html Regression testing (jtreg and jck) did not show issues. This bug references a CSR but it was withdrawn since no API changes were made.

URL: https://hg.openjdk.java.net/jdk/jdk/rev/99d2dd7b84a8 User: naoto Date: 2019-07-26 15:57:36 +0000

Currently, the tz data file "tzdb.dat" is simply a serialized objects of ZoneRules. This means that the build bootjdk should have capability of creating ZoneOffsetTransitionRule with duration. This is problematic as the bootstrap jdk is older JDKs which do not have duration capability.