Hi Naoto,
The method findNegativeSavings method in TzdbZoneRulesProvider.java
states that it "Find the minimum negative savings". While the result is
correct since the rules all have the same value for SAVE, I wonder if
that's ideal conceptually. Given a start LDT, shouldn't it be looking
for the SAVE in the exact (narrower) date range (e.g. 1981 - 1989 vs
1981 - max)?.
NegativeDSTTest verifies the tzdata, that is the adjusted data after
import, is that correct? I wonder a comment and a bit of details in the
test summary would be helpful since there is no negative data in the
test itself.
Best,
Joe
On 7/23/19 3:15 PM, naoto.s...@oracle.com wrote:
Hi,
Please review the fix to the following enhancement:
https://bugs.openjdk.java.net/browse/JDK-8212970
The proposed changeset is located at:
https://cr.openjdk.java.net/~naoto/8212970/webrev.09/
This change aims to support the "vanguard" IANA time zone data format,
which uses the negative savings and transition time beyond a day
period. The change basically translates those negative savings and
transition times, such as 25:00, into the ones that the current JDK
recognizes, then produces the data file "tzdb.dat" at the build time.
At the run time, the data file is read and interpreted as before. This
way the produced tzdb.dat is compatible with the prior JDK releases so
that the TZ Updater can also distribute it as a time zone update.
I have also refactored redundant copy of ZoneRules file in the build
directory, by dynamically importing the file under src. Thus some
build related files are modified. I am hoping folks on the build-dev
can review those changes.
Naoto
