<i18n dev> RFR: 8224560: (tz) Upgrade time-zone data to tzdata2019a and 8225580: tzdata2018i integration causes test failures on jdk-13

[Ramanand Patil]

Hi all,
Please review the patch for tzdata2019a integration into jdk project.
Webrev: http://cr.openjdk.java.net/~rpatil/8224560/webrev.00/
Bugs: https://bugs.openjdk.java.net/browse/JDK-8224560
https://bugs.openjdk.java.net/browse/JDK-8225580

Summary:
- The fix contains cumulative tzdata changes from tzdata2018i and tzdata2019a, as tzdata2018i was not integrated into jdk/jdk earlier.
- In JDK-13/14, multiple failures were seen during integration of tzdata2018i (JDK-8225580), those are fixed now. Many thanks to Naoto for providing a fix for this in CLDRConverter.java.
- There are 2 type of test failures in TestZoneInfo310.java file, which are solved in this patch by providing workarounds, But a permanent fix needs to be added in future for the same. Below are the 2 bugs created to track the development on it:
	1. https://bugs.openjdk.java.net/browse/JDK-8223388: TestZoneInfo310.java fails post tzdata2018i integration:
This failure is seen for the TimeZones which are having zone rules defined till year 2037 or beyond. For now, the failing zones are skipped.
The supporting test class ZoneInfo.java has maxYear defined http://hg.openjdk.java.net/jdk/jdk/file/d01b345865d7/test/jdk/sun/util/calendar/zi/Zoneinfo.java#l40, changing this max value greater than the zone rule's last year also fixes the issue, but further investigation is needed on why this boundary condition is affecting the test behavior.
	2. JDK-8227293: https://bugs.openjdk.java.net/browse/JDK-8227293 TestZoneInfo310.java fails post tzdata2019a integration for Palestine zone rules:
There are many hacks and assumptions in the class sun.util.calendar.ZoneInfoFile.java. This issue looks because of the code starting from here: http://hg.openjdk.java.net/jdk/jdk/file/963924f1c891/src/java.base/share/classes/sun/util/calendar/ZoneInfoFile.java#l552
There is an assumption where the transition date is >=24,(line 577 and 599) it assumes it is the "last" rule, but it is not last rule in case of Asia/Gaza and Asia/Hebron zones.
For now, I have fixed these 2 problematic timezones by overwriting the assumption made on line 577, where date of month dom = startRule.dom;
I think, overriding of the second jdk hack on line 599 is not required as the "dom" is calculated from the last rule there. Keeping this bug open as we need to find a generic solution for this issue, without hard-coding the values and adding specific time zone names in exclusion as seen in many places in this class file.

- The patch has passed all the related testing including JCK tests.


Regards,
Ramanand.