JDK-8157792 : After Integrating tzdata2016d the test/sun/util/calendar/zi/TestZoneInfo310.java fails for "Asia/Oral" and "Asia/Qyzylorda" Timezones
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.util:i18n
  • Affected Version: 9
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2016-05-25
  • Updated: 2020-01-15
  • Resolved: 2016-08-30
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 9 Other
9 b135Fixed openjdk8u222Fixed
Related Reports
Relates :  
Relates :  
Description
Integrating the tzdata2016d from IANA, causes sun/util/calendar/zi/TestZoneInfo310.java to fail with below error:

Asia/Oral : Asia/Oral
    offset=18000000,dstSavings=0,useDaylight=false,transitions=53,offsets=5,checksum=1105612483,gmtChanged=false
[NG]offset=18000000,dstSavings=0,useDaylight=false,transitions=52,offsets=5,checksum=1825924055,gmtChanged=false
    -------------
    (NG) Different trans size :53, 52
                  1900-01-01T00:00  [utc=-2208988800   raw=fffffdfdae01dc00, offset=12324/+03:25:24, saving=0]
    (OK)          1900-01-01T00:00  [utc=-2208988800   raw=fffffdfdae01dc00, offset=12324/+03:25:24, saving=0]
            -----
            .
            .
            .
    (OK)          1991-03-31T02:00  [utc=670370400   raw=9c15308700, offset=18000/+05:00, saving=3600]
            -----
                  1991-09-29T03:00  [utc=686095200   raw=9fbe75ef00, offset=14400/+04:00, saving=0]
    (OK)          1991-09-29T03:00  [utc=686095200   raw=9fbe75ef00, offset=14400/+04:00, saving=0]
            -----
                  1992-01-19T02:00  [utc=695772000   raw=a1ff3e2f00, offset=18000/+05:00, saving=0]
    (NG)          1992-03-29T01:00  [utc=701816400   raw=a367846880, offset=18000/+05:00, saving=3600]
            -----
                  1992-03-29T02:00  [utc=701816400   raw=a367846880, offset=18000/+05:00, saving=3600]
    (NG)          1992-09-27T03:00  [utc=717544800   raw=a71100bf00, offset=14400/+04:00, saving=0]
            -----
                  1992-09-27T03:00  [utc=717544800   raw=a71100bf00, offset=14400/+04:00, saving=0]
    (NG)          1993-03-28T02:00  [utc=733269600   raw=aaba462700, offset=18000/+05:00, saving=3600]
            -----
            .
            .
            .
            -----
                  2004-10-31T03:00  [utc=1099173600   raw=ffebda1b00, offset=18000/+05:00, saving=0]
    (NG)          2037-01-01T00:00  [utc=2114362800   raw=1ec49d7f780, offset=18000/+05:00, saving=0]
    
    
    

Looks like the historical transistion changes around 1992 for Asia/Oral TimeZone has caused this failure.

Here is the IANA patch for this timezone:

+# West Kazakhstan (KZ-ZAP)
+# From Paul Eggert (2016-03-18):
+# The 1989 transition is from USSR act No. 227 (1989-03-14).
 Zone	Asia/Oral	3:25:24	-	LMT	1924 May  2 # or Ural'sk
-			4:00	-	URAT	1930 Jun 21 # Ural'sk time
-			5:00	-	URAT	1981 Apr  1
-			5:00	1:00	URAST	1981 Oct  1
-			6:00	-	URAT	1982 Apr  1
-			5:00 RussiaAsia	URA%sT	1989 Mar 26  2:00
-			4:00 RussiaAsia	URA%sT	1991
-			4:00	-	URAT	1991 Dec 16 # independence
-			4:00 RussiaAsia	ORA%sT	2005 Mar 15 # Oral Time
-			5:00	-	ORAT
+			4:00	-	+04	1930 Jun 21
+			5:00	-	+05	1981 Apr  1
+			5:00	1:00	+06	1981 Oct  1
+			6:00	-	+06	1982 Apr  1
+			5:00 RussiaAsia	+05/+06	1989 Mar 26  2:00s
+			4:00 RussiaAsia	+04/+05	1992 Jan 19  2:00s
+			5:00 RussiaAsia	+05/+06	1992 Mar 29  2:00s
+			4:00 RussiaAsia	+04/+05	2004 Oct 31  2:00s
+			5:00	-	+05

And similar failure is observed for "Asia/Qyzylorda".


Comments
8u fix request: Applies cleanly, bar a little fuzz to @modules in OpenJDK 9+. Test passes with most recent release (8u212).
07-07-2019

Note also that the affected timezone used the RussiaAsia DST rules : Rule RussiaAsia 1981 1983 - Oct 1 0:00 0 - Rule RussiaAsia 1984 1995 - Sep lastSun 2:00s 0 - Rule RussiaAsia 1985 2011 - Mar lastSun 2:00s 1:00 S Rule RussiaAsia 1996 2011 - Oct lastSun 2:00s 0 - The Mar 29th GMT transition from +4 to +5 occurs at same time as the DST change. Maybe the compiler cancels the DST change for the GMT change. Need to figure out which implementation is incorrect.
25-05-2016