JDK-8216178 : (tz) Upgrade time-zone data to tzdata2018i
  • Type: Enhancement
  • Component: core-libs
  • Sub-Component: java.time
  • Priority: P2
  • Status: Closed
  • Resolution: Duplicate
  • Submitted: 2019-01-04
  • Updated: 2019-04-01
  • Resolved: 2019-04-01
Related Reports
Duplicate :  
JDK-8215982 - (tz) Upgrade time-zone data to tzdata2018i
Description
Need to integrate tzdata2018h and tzdata2018i

https://mm.icann.org/pipermail/tz-announce/2018-December/000053.html
https://mm.icann.org/pipermail/tz-announce/2018-December/000054.html
Comments
I was not the only one having trouble with Africa/Casablanca. See thread near https://mm.icann.org/pipermail/tz/2019-January/027372.html
05-01-2019
Here's the naive import of "rearguard" tzdata files into openjdk: https://cr.openjdk.java.net/~martin/webrevs/jdk/tzdata2018i/ But it results in 3 test failures: java/time/tck/java/time/format/TCKDateTimeFormatterBuilder.java java/time/test/java/time/format/TestZoneTextPrinterParser.java sun/util/calendar/zi/TestZoneInfo310.java (you should be able to repro those failures easily) (These test failures are not very informative - we should fix that!)
04-01-2019
One of the problems is due to the addition of a new timezone in Kazakhstan, caused by the split of an existing timezone into two. I have no idea how to incorporate a new timezone into openjdk - it will need additions to TimeZoneNames, but where to get the new localized names for the timezones? Coordinate with cldr? I tried naively deleting the new Qostanay definition in "asia" : --- a/make/data/tzdata/asia +++ b/make/data/tzdata/asia @@ -2199,19 +2199,6 @@ 5:00 RussiaAsia +05/+06 2004 Oct 31 2:00s 6:00 - +06 2018 Dec 21 0:00 5:00 - +05 -# -# Qostanay (aka Kostanay, Kustanay) (KZ-KUS) -# The 1991/2 rules are unclear partly because of the 1997 Turgai -# reorganization. -Zone Asia/Qostanay 4:14:28 - LMT 1924 May 2 - 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 1991 Mar 31 2:00s - 4:00 RussiaAsia +04/+05 1992 Jan 19 2:00s - 5:00 RussiaAsia +05/+06 2004 Oct 31 2:00s - 6:00 - +06 which fixed two of the failing tests, leaving this failure in sun/util/calendar/zi/TestZoneInfo310.java Africa/Casablanca : Africa/Casablanca offset=0,dstSavings=0,useDaylight=false,transitions=95,offsets=3,checksum=254320564,gmtChanged=false [NG]offset=3600000,dstSavings=0,useDaylight=false,transitions=57,offsets=4,checksum=966810923,gmtChanged=false offset.len=3 4 Z +01:00 -00:30:20 -00:30:20 +01:00 Z +01:00 ... java.lang.RuntimeException: FAILED: Africa/Casablanca at TestZoneInfo310.main(TestZoneInfo310.java:175) I do see some updates to the Africa/Casablanca definition in "africa" that are likely to be responsible. My expertise ends at this point.
04-01-2019