tzdata2018g.tar.gz failing to install in Java 8
Iana team: I am getting the following when trying to install tzdata2018g.tar.gz using the latest tzupdater.jar (2.2.0) for Java 8. Failed: java.lang.Exception: Failed while parsing file '/tmp/tz.tmp_5/asia' on line 1655 'Rule Japan 1948 1951 - Sep Sat>=8 25:00 0 S' java.lang.Exception: Failed while parsing file '/tmp/tz.tmp_5/asia' on line 1655 'Rule Japan 1948 1951 - Sep Sat>=8 25:00 0 S' at tools.tzdb.TzdbZoneRulesCompiler.parseFile(TzdbZoneRulesCompiler.java:377) at tools.tzdb.TzdbZoneRulesCompiler.compile(TzdbZoneRulesCompiler.java:191) at tools.tzdb.TzdbZoneRulesCompiler.<init>(TzdbZoneRulesCompiler.java:307) at com.sun.tools.tzupdater.ExternalModule.compileToJSRBinary(ExternalModule.java:153) at com.sun.tools.tzupdater.TimezoneUpdater.run(TimezoneUpdater.java:230) at com.sun.tools.tzupdater.TimezoneUpdater.main(TimezoneUpdater.java:634) Caused by: tools.tzdb.DateTimeException: Invalid value for SecondOfDay value: 90000 at tools.tzdb.ChronoField.checkValidValue(ChronoField.java:173) at tools.tzdb.LocalTime.ofSecondOfDay(LocalTime.java:210) at tools.tzdb.TzdbZoneRulesCompiler.parseMonthDayTime(TzdbZoneRulesCompiler.java:475) at tools.tzdb.TzdbZoneRulesCompiler.parseRuleLine(TzdbZoneRulesCompiler.java:399) at tools.tzdb.TzdbZoneRulesCompiler.parseFile(TzdbZoneRulesCompiler.java:354) ... 5 more Please advise when will this be fixed? Thanks, Tom L Carter Principal Architect: CS/BW, American Airlines Work#: (817) 963-7640 Cell: (972) 849-1416 Coordinates: 4N-5A-53@HDQ2 Meeting Room<https://americanairlines.webex.com/join/Tom.Carter> NOTICE: This email and any attachments are for the exclusive and confidential use of the intended recipient(s). If you are not an intended recipient, please do not read, distribute, or take action in reliance upon this message. If you have received this in error, please notify me immediately by return email and promptly delete this message and its attachments from your computer.
Is anyone notifying the vendors that this does not work for Java 8? [Description: Description: cid:49F8CA06-65F7-457B-9DC0-8251F696295B] Karen Long Manager IT Operation//Production Support From: Carter, Tom Sent: Tuesday, October 30, 2018 10:53 AM To: tz@iana.org Cc: Nallamilli, Satish <Satish.Nallamilli@aa.com>; Long, Karen <Karen.Long@aa.com>; Carter, Tom <Tom.Carter@aa.com>; CSSupport <CSSupport@aa.com> Subject: tzdata2018g.tar.gz failing to install in Java 8 Iana team: I am getting the following when trying to install tzdata2018g.tar.gz using the latest tzupdater.jar (2.2.0) for Java 8. Failed: java.lang.Exception: Failed while parsing file '/tmp/tz.tmp_5/asia' on line 1655 'Rule Japan 1948 1951 - Sep Sat>=8 25:00 0 S' java.lang.Exception: Failed while parsing file '/tmp/tz.tmp_5/asia' on line 1655 'Rule Japan 1948 1951 - Sep Sat>=8 25:00 0 S' at tools.tzdb.TzdbZoneRulesCompiler.parseFile(TzdbZoneRulesCompiler.java:377) at tools.tzdb.TzdbZoneRulesCompiler.compile(TzdbZoneRulesCompiler.java:191) at tools.tzdb.TzdbZoneRulesCompiler.<init>(TzdbZoneRulesCompiler.java:307) at com.sun.tools.tzupdater.ExternalModule.compileToJSRBinary(ExternalModule.java:153) at com.sun.tools.tzupdater.TimezoneUpdater.run(TimezoneUpdater.java:230) at com.sun.tools.tzupdater.TimezoneUpdater.main(TimezoneUpdater.java:634) Caused by: tools.tzdb.DateTimeException: Invalid value for SecondOfDay value: 90000 at tools.tzdb.ChronoField.checkValidValue(ChronoField.java:173) at tools.tzdb.LocalTime.ofSecondOfDay(LocalTime.java:210) at tools.tzdb.TzdbZoneRulesCompiler.parseMonthDayTime(TzdbZoneRulesCompiler.java:475) at tools.tzdb.TzdbZoneRulesCompiler.parseRuleLine(TzdbZoneRulesCompiler.java:399) at tools.tzdb.TzdbZoneRulesCompiler.parseFile(TzdbZoneRulesCompiler.java:354) ... 5 more Please advise when will this be fixed? Thanks, Tom L Carter Principal Architect: CS/BW, American Airlines Work#: (817) 963-7640 Cell: (972) 849-1416 Coordinates: 4N-5A-53@HDQ2 Meeting Room<https://americanairlines.webex.com/join/Tom.Carter> NOTICE: This email and any attachments are for the exclusive and confidential use of the intended recipient(s). If you are not an intended recipient, please do not read, distribute, or take action in reliance upon this message. If you have received this in error, please notify me immediately by return email and promptly delete this message and its attachments from your computer.
On 10/30/18 9:48 AM, Long, Karen via tz wrote:
Is anyone notifying the vendors that this does not work for Java 8?
There have been notifications on the tz-announce and tz mailing lists, and the Java folks know about it. See, for example: https://bugs.openjdk.java.net/browse/JDK-8213016 It shouldn't hurt to notify your specific vendors about the issue too, so that everyone can put 2 and 2 together.
Paul and Tom, Does tz2018g include an update for Turks and Caico? Our information for Providenciales (PLS) is incorrect starting on 4 Nov. Karen Long Manager IT Operation//Production Support -----Original Message----- From: Paul Eggert [mailto:eggert@cs.ucla.edu] Sent: Tuesday, October 30, 2018 2:55 PM To: Long, Karen <Karen.Long@aa.com>; Carter, Tom <Tom.Carter@aa.com>; Time Zone Mailing List <tz@iana.org> Cc: CSSupport <CSSupport@aa.com>; Nallamilli, Satish <Satish.Nallamilli@aa.com> Subject: Re: [tz] tzdata2018g.tar.gz failing to install in Java 8 On 10/30/18 9:48 AM, Long, Karen via tz wrote:
Is anyone notifying the vendors that this does not work for Java 8?
There have been notifications on the tz-announce and tz mailing lists, and the Java folks know about it. See, for example: https://bugs.openjdk.java.net/browse/JDK-8213016 It shouldn't hurt to notify your specific vendors about the issue too, so that everyone can put 2 and 2 together. NOTICE: This email and any attachments are for the exclusive and confidential use of the intended recipient(s). If you are not an intended recipient, please do not read, distribute, or take action in reliance upon this message. If you have received this in error, please notify me immediately by return email and promptly delete this message and its attachments from your computer.
Long, Karen wrote:
Does tz2018g include an update for Turks and Caico?
Our information for Providenciales (PLS) is incorrect starting on 4 Nov.
According to our sources last year, Turks & Caicos adopted Eastern time with US daylight-saving rules effective 2018-03-11 03:00. So, starting with tzdb 2017c America/Grand_Turk has been scheduled to fall back about 90 minutes from now, i.e., from Sun Nov 4 01:59:59 2018 -04 (EDT) to Sun Nov 4 01:00:00 2018 -05 (EST) one second later. This agrees with an article in a newspaper last week cited below containing an advisory from the Turks & Caicos government. So as far as I can see, tzdb is should be OK for this transition. If you have information to the contrary please let us know the details so that we can fix tzdb. Hamilton D. Daylight Savings Time Ends November 4, 2018. Magnetic Media. 2018-10-25. https://magneticmediatv.com/2018/10/daylight-savings-time-ends-november-4-20...
Chuck or Rajat, Who is working with Paul on this issue? Our displays for PLS using this tzdata are incorrect since Sunday. Karen Long Manager IT Operation//Production Support -----Original Message----- From: Paul Eggert [mailto:eggert@cs.ucla.edu] Sent: Saturday, November 03, 2018 11:30 PM To: Long, Karen <Karen.Long@aa.com>; Carter, Tom <Tom.Carter@aa.com> Cc: Time Zone Mailing List <tz@iana.org> Subject: Re: Turks & Caicos DST transition November 4 02:00 Long, Karen wrote:
Does tz2018g include an update for Turks and Caico?
Our information for Providenciales (PLS) is incorrect starting on 4 Nov.
According to our sources last year, Turks & Caicos adopted Eastern time with US daylight-saving rules effective 2018-03-11 03:00. So, starting with tzdb 2017c America/Grand_Turk has been scheduled to fall back about 90 minutes from now, i.e., from Sun Nov 4 01:59:59 2018 -04 (EDT) to Sun Nov 4 01:00:00 2018 -05 (EST) one second later. This agrees with an article in a newspaper last week cited below containing an advisory from the Turks & Caicos government. So as far as I can see, tzdb is should be OK for this transition. If you have information to the contrary please let us know the details so that we can fix tzdb. Hamilton D. Daylight Savings Time Ends November 4, 2018. Magnetic Media. 2018-10-25. https://magneticmediatv.com/2018/10/daylight-savings-time-ends-november-4-20... NOTICE: This email and any attachments are for the exclusive and confidential use of the intended recipient(s). If you are not an intended recipient, please do not read, distribute, or take action in reliance upon this message. If you have received this in error, please notify me immediately by return email and promptly delete this message and its attachments from your computer.
On 2018-11-03 14:07, Long, Karen via tz wrote:
On Tuesday, October 30, 2018 2:55 PM, Paul Eggert wrote:
On 10/30/18 9:48 AM, Long, Karen via tz wrote:
Is anyone notifying the vendors that this does not work for Java 8?
There have been notifications on the tz-announce and tz mailing lists, and the Java folks know about it. See, for example: https://bugs.openjdk.java.net/browse/JDK-8213016 It shouldn't hurt to notify your specific vendors about the issue too, so that everyone can put 2 and 2 together.
Does tz2018g include an update for Turks and Caico? Our information for Providenciales (PLS) is incorrect starting on 4 Nov.
What about time at JAGS McCartney International Airport GDT/MBGT on Grand Turk? T&C rules were updated in tzdata 2017c with info from July and August: +# From the Turks & Caicos Cabinet (2017-07-20), heads-up from Steffen Thorsen: +# ... agreed to the reintroduction in TCI of Daylight Saving Time (DST) +# during the summer months and Standard Time, also known as Local +# Time, during the winter months with effect from April 2018 ... +# https://www.gov.uk/government/news/turks-and-caicos-post-cabinet-meeting-sta... +# +# From Paul Eggert (2017-08-26): +# The date of effect of the spring 2018 change appears to be March 11, +# which makes more sense. See: Hamilton D. Time change back +# by March 2018 for TCI. Magnetic Media. 2017-08-25. +# http://magneticmediatv.com/2017/08/time-change-back-by-march-2018-for-tci/ +# # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone America/Grand_Turk -4:44:32 - LMT 1890 -5:07:11 - KMT 1912 Feb # Kingston Mean Time -5:00 - EST 1979 -5:00 US E%sT 2015 Nov Sun>=1 2:00 - -4:00 - AST + -4:00 - AST 2018 Mar 11 3:00 + -5:00 US E%sT It would help diagnose issues if you could provide distro or package version info and time change diagnostics like: $ apt list tzdata tzcode tzcode 2018e-1 x86_64 [installed, manual] tzdata 2018e-1 x86_64 [installed, automatic] $ zdump --version zdump (tzcode) 2018e $ zdump -Vc`date +%Y`,`date -d'next year' +%Y` America/Grand_Turk America/Grand_Turk Sun Mar 11 06:59:59 2018 UT = Sun Mar 11 02:59:59 2018 AST isdst=0 gmtoff=-14400 America/Grand_Turk Sun Mar 11 07:00:00 2018 UT = Sun Mar 11 03:00:00 2018 EDT isdst=1 gmtoff=-14400 America/Grand_Turk Sun Nov 4 05:59:59 2018 UT = Sun Nov 4 01:59:59 2018 EDT isdst=1 gmtoff=-14400 America/Grand_Turk Sun Nov 4 06:00:00 2018 UT = Sun Nov 4 01:00:00 2018 EST isdst=0 gmtoff=-18000 -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised.
On 10/30/18 8:52 AM, Carter, Tom via tz wrote:
Please advise when will this be fixed?
As announced in <https://mm.icann.org/pipermail/tz-announce/2018-October/000052.html> a rearguard-format tarball <https://web.cs.ucla.edu/~eggert/tz/release/2018g/tzdata2018g-rearguard.tar.g...> is intended to be usable by programs that don't yet support the timestamps in question. Please give that tarball a try and let us know of any problems with it. Although the timestamp format was changed in 2007 this change was evidently overlooked in TZUpdater. Sorry, I don't know when TZUpdater itself will be fixed to support these timestamps; TZUpdater is a separate project maintained by a different group.
On Tue, 30 Oct 2018 at 19:42, Paul Eggert <eggert@cs.ucla.edu> wrote:
On 10/30/18 8:52 AM, Carter, Tom via tz wrote:
Please advise when will this be fixed?
As announced in <https://mm.icann.org/pipermail/tz-announce/2018-October/000052.html> a rearguard-format tarball <https://web.cs.ucla.edu/~eggert/tz/release/2018g/tzdata2018g-rearguard.tar.g...> is intended to be usable by programs that don't yet support the timestamps in question. Please give that tarball a try and let us know of any problems with it.
Although the timestamp format was changed in 2007 this change was evidently overlooked in TZUpdater. Sorry, I don't know when TZUpdater itself will be fixed to support these timestamps; TZUpdater is a separate project maintained by a different group.
I made a very specific request to put 01:00 back in the main file for 15 months. A timeframe that would allow fixed/updated tools to be rolled out. Had my request and advice been followed, these developers and many others would not be frustrated today. FWIW, I've done my part - there are new releases of both time-zone parsers that I directly control (Joda-Time and ThreeTen-Backport), and I have argued for changes to the JDK. But changes to the JDK or TZUpdater will not be quick. I say again, the right course of action is to revert the change and use 01:00 in the main file until the JDK teams have had a chance to fix their tools. Stephen
<<On Tue, 30 Oct 2018 23:23:10 +0000, Stephen Colebourne <scolebourne@joda.org> said:
I say again, the right course of action is to revert the change and use 01:00 in the main file until the JDK teams have had a chance to fix their tools.
I believe Paul has repeatedly responded that the right course of action is for the Java distributors to distribute their own copies of Java-compatible data files rather than expecting IANA to do so. -GAWollman
On Tue, Oct 30, 2018 at 12:42:23PM -0700, Paul Eggert wrote:
On 10/30/18 8:52 AM, Carter, Tom via tz wrote:
Please advise when will this be fixed?
As announced in <https://mm.icann.org/pipermail/tz-announce/2018-October/000052.html> a rearguard-format tarball <https://web.cs.ucla.edu/~eggert/tz/release/2018g/tzdata2018g-rearguard.tar.g...> is intended to be usable by programs that don't yet support the timestamps in question. Please give that tarball a try and let us know of any problems with it.
Yes, the rearguard-format tarball is OK for https://omajid.fedorapeople.org/javazic-1.8-37392f2f5d59.tar.xz which is used by many GNU/Linux distributions. -- ldv
participants (7)
-
Brian Inglis -
Carter, Tom -
Dmitry V. Levin -
Garrett Wollman -
Long, Karen -
Paul Eggert -
Stephen Colebourne