JDK relies on the time zone data from IANA time zone database.  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 , API enhancements were suggested, but not doing so by taking the backward compatibility into consideration.