JDK-8227293 : TestZoneInfo310.java fails post tzdata2019a integration for Palestine zone rules
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.time
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • OS: generic
  • CPU: generic
  • Submitted: 2019-07-05
  • Updated: 2020-11-03
Related Reports
Relates :  
Relates :  
Description
test/jdk/sun/util/calendar/zi/TestZoneInfo310.java fails with below error post integration of tzdata2019a:

******************************
Asia/Gaza : Asia/Gaza
    -------------
    SimpleTimeZone (NG)
       stz=java.util.SimpleTimeZone[id=Asia/Gaza,offset=7200000,dstSavings=3600000,useDaylight=true,startYear=0,startMode=2,startMonth=2,startDay=-1,startDayOfWeek=7,startTime=3600000,startTimeMode=0,endMode=2,endMonth=9,endDay=-1,endDayOfWeek=7,endTime=3600000,endTimeMode=0]
      stz0=java.util.SimpleTimeZone[id=Asia/Gaza,offset=7200000,dstSavings=3600000,useDaylight=true,startYear=0,startMode=3,startMonth=2,startDay=24,startDayOfWeek=7,startTime=3600000,startTimeMode=0,endMode=2,endMonth=9,endDay=-1,endDayOfWeek=7,endTime=3600000,endTimeMode=0]
    -------------
Comments
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" in case of Asia/Gaza and Asia/Hebron zones. For now, we can fix this for the 2 problematic timezones, but we need to have a generic solution for this issue, without hard-coding the values and adding specific TimeZone name exceptions as seen many places in this class.
05-07-2019