JDK-8157814 : Integrating tzdata2016d causes test/java/text/Format/DateFormat/Bug8081794.java to fail with wrong errorindex
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.text
  • Affected Version: 9
  • Priority: P3
  • Status: Resolved
  • Resolution: Not an Issue
  • OS: generic
  • CPU: generic
  • Submitted: 2016-05-25
  • Updated: 2016-06-14
  • Resolved: 2016-06-14
Related Reports
Relates :  
Description
As per the IANA released tzdata2016d integration changes to JDK, few TimeZoneNames started to follow the the new numeric naming conventions for abrreviations(e.g. for TimeZone "Asia/Almaty" the short name became "+06" instead of "ALMT").
To reflect this changes and fallback to JDKs default format of "GMT[+-]hh:mm", these TimeZoneNames were removed from the resources.

And this test case failure is caused by removal of time zone names entries from TimeZoneNames*.java files. Only timezone names were removed, but the list of timezones is still stored  in tzdb.dat file.
For removed timezones all zone names(long, short) will be empty strings. When SimpleDateFormat class searches for requested timezone name ("ABC" in our test case) and encounters first zone with empty name, this timezone faulty considered as the requested timezone.
(regionMatches call with '' and 'ABC' strings: 0 length region match)

Test failure can be solved by this patch:
--- a/src/java.base/share/classes/java/text/SimpleDateFormat.java    Tue May 24 12:31:30 2016 +0100
+++ b/src/java.base/share/classes/java/text/SimpleDateFormat.java    Wed May 25 01:20:02 2016 +0300
@@ -1635,8 +1635,8 @@
             // Checking long and short zones [1 & 2],
             // and long and short daylight [3 & 4].
             String zoneName = zoneNames[i];
-            if (text.regionMatches(true, start,
-                                   zoneName, 0, zoneName.length())) {
+            if (!zoneName.isEmpty() && text.regionMatches(true, start,
+                                       zoneName, 0, zoneName.length())) {
                 return i;
             }
         }

[Thanks to [~aefimov]] for investigating this bug].
Comments
As discussed in the review thread of the main bug, it was decided to not remove the existing TimeZoneNames from the resources, and hence this test case no more fails.
01-06-2016