Please remove tzdata2018f
Hello Paul/Team, While doing tzdata upgrade to version 2018f, we found below issue. java.lang.Exception: Failed while parsing file '/tmp/tz.tmp/asia' on line 1842 '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:226) at com.sun.tools.tzupdater.TimezoneUpdater.run(TimezoneUpdater.java:222) at com.sun.tools.tzupdater.TimezoneUpdater.main(TimezoneUpdater.java:643) 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 We further found that the issue was addressed in version 2018g. To avoid any reoccurrence of same, would it be possible to prevent the tzdata version 2018f from downloading on iana site? [Ericsson]<http://www.ericsson.com/> ANKUR RANA Senior Software Developer Bussiness Area Digital Services - Development Unit Ericsson Block A, King Canyon "ASF Insignia" THE IT/ITES SEZ, Faridabad Road, Gawal Pahari, Gurgaon 122003, India Phone +91-124-3088600 Mobile +91-9811264594 ankur.rana@ericsson.com www.ericsson.com [http://www.ericsson.com/current_campaign]<http://www.ericsson.com/current_campaign> Legal entity: Ericsson India Global Services Pvt Ltd, registered office in Gurgaon. This Communication is Confidential. We only send and receive email on the basis of the terms set out at www.ericsson.com/email_disclaimer<http://www.ericsson.com/email_disclaimer>
On 2/20/19 11:31 PM, Ankur Rana wrote:
would it be possible to prevent the tzdata version 2018f from downloading on iana site?
Although it would be possible I doubt whether it would be a good idea. 2018f does work for many downstream users, and these users wouldn't benefit by its withdrawal from publication. Besides, standard practice should be to use the latest version, falling back on a previous version only if there's trouble.
On 2019-02-21 16:31:39 (+0900), Ankur Rana wrote:
While doing tzdata upgrade to version 2018f
Note that you should really be upgrading to 2018i, which is the latest version.
java.lang.Exception: Failed while parsing file '/tmp/tz.tmp/asia' on line 1842 'Rule Japan 1948 1951 - Sep Sat>=8 25:00 0 S'
Java is known to be broken with respect to the last ten years or so of changes to the tzdb data format. You'll need to generate "rearguard" format data to feed to the Java updater. Paul also helpfully provides rearguard tarballs on his webpage https://web.cs.ucla.edu/~eggert/tz/release/. You can easily generate those yourself by running make rearguard_tarballs on the distribution from iana.org.
To avoid any reoccurrence of same, would it be possible to prevent the tzdata version 2018f from downloading on iana site?
It seems silly to pull one release from an archive going back to 1993 because one third-party implementation (even if it's a popular one) cannot cope with the data format. Philip -- Philip Paeps Senior Reality Engineer Ministry of Information
Stephen can confirm it, but I built all versions since 2018 using JSR-310 a few months and the result was correct. On Thu, Feb 21, 2019 at 21:55 Philip Paeps <philip@trouble.is> wrote:
On 2019-02-21 16:31:39 (+0900), Ankur Rana wrote:
While doing tzdata upgrade to version 2018f
Note that you should really be upgrading to 2018i, which is the latest version.
java.lang.Exception: Failed while parsing file '/tmp/tz.tmp/asia' on line 1842 'Rule Japan 1948 1951 - Sep Sat>=8 25:00 0 S'
Java is known to be broken with respect to the last ten years or so of changes to the tzdb data format. You'll need to generate "rearguard" format data to feed to the Java updater.
Paul also helpfully provides rearguard tarballs on his webpage https://web.cs.ucla.edu/~eggert/tz/release/.
You can easily generate those yourself by running make rearguard_tarballs on the distribution from iana.org.
To avoid any reoccurrence of same, would it be possible to prevent the tzdata version 2018f from downloading on iana site?
It seems silly to pull one release from an archive going back to 1993 because one third-party implementation (even if it's a popular one) cannot cope with the data format.
Philip
-- Philip Paeps Senior Reality Engineer Ministry of Information
*a few months ago On Thu, Feb 21, 2019 at 22:14 Marcos Passos <marcospassos.com@gmail.com> wrote:
Stephen can confirm it, but I built all versions since 2018 using JSR-310 a few months and the result was correct.
On Thu, Feb 21, 2019 at 21:55 Philip Paeps <philip@trouble.is> wrote:
On 2019-02-21 16:31:39 (+0900), Ankur Rana wrote:
While doing tzdata upgrade to version 2018f
Note that you should really be upgrading to 2018i, which is the latest version.
java.lang.Exception: Failed while parsing file '/tmp/tz.tmp/asia' on line 1842 'Rule Japan 1948 1951 - Sep Sat>=8 25:00 0 S'
Java is known to be broken with respect to the last ten years or so of changes to the tzdb data format. You'll need to generate "rearguard" format data to feed to the Java updater.
Paul also helpfully provides rearguard tarballs on his webpage https://web.cs.ucla.edu/~eggert/tz/release/.
You can easily generate those yourself by running make rearguard_tarballs on the distribution from iana.org.
To avoid any reoccurrence of same, would it be possible to prevent the tzdata version 2018f from downloading on iana site?
It seems silly to pull one release from an archive going back to 1993 because one third-party implementation (even if it's a popular one) cannot cope with the data format.
Philip
-- Philip Paeps Senior Reality Engineer Ministry of Information
On 2019-02-22 10:14:52 (+0900), Marcos Passos wrote:
On Thu, Feb 21, 2019 at 21:55 Philip Paeps <philip@trouble.is> wrote:
On 2019-02-21 16:31:39 (+0900), Ankur Rana wrote:
While doing tzdata upgrade to version 2018f
Note that you should really be upgrading to 2018i, which is the latest version.
java.lang.Exception: Failed while parsing file '/tmp/tz.tmp/asia' on line 1842 'Rule Japan 1948 1951 - Sep Sat>=8 25:00 0 S'
Java is known to be broken with respect to the last ten years or so of changes to the tzdb data format. You'll need to generate "rearguard" format data to feed to the Java updater.
Stephen can confirm it, but I built all versions since 2018 using JSR-310 a few months and the result was correct.
Good to know! Last I read on the tz mailing list, the Java tzdb parser doesn't like negative SAVE rules or more than 24 hours in a day. Happy to hear that was fixed at last. Thank you for pointing that out. Philip -- Philip Paeps Senior Reality Engineer Ministry of Information
On 2019-02-21 18:19, Philip Paeps wrote:
On 2019-02-22 10:14:52 (+0900), Marcos Passos wrote:
On Thu, Feb 21, 2019 at 21:55 Philip Paeps <philip@trouble.is> wrote:
On 2019-02-21 16:31:39 (+0900), Ankur Rana wrote:
While doing tzdata upgrade to version 2018f
Note that you should really be upgrading to 2018i, which is the latest version.
java.lang.Exception: Failed while parsing file '/tmp/tz.tmp/asia' on line 1842 'Rule Japan 1948 1951 - Sep Sat>=8 25:00 0 S'
Java is known to be broken with respect to the last ten years or so of changes to the tzdb data format. You'll need to generate "rearguard" format data to feed to the Java updater.
Stephen can confirm it, but I built all versions since 2018 using JSR-310 a few months and the result was correct.
Last I read on the tz mailing list, the Java tzdb parser doesn't like negative SAVE rules or more than 24 hours in a day. Happy to hear that was fixed at last. Thank you for pointing that out.
Marcos didn't say whether it was vanguard, standard, or rearguard format data that was used for 2018. As JSR 310 appears to be unchanged since 2014, until Marcos or Stephen explicitly states otherwise, it would be safer to continue to assume that rearguard format data is required. -- 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.
Brian, I used these files: https://data.iana.org/time-zones/releases/ Regards, Marcos On Fri, Feb 22, 2019 at 01:01 Brian Inglis <Brian.Inglis@systematicsw.ab.ca> wrote:
On 2019-02-21 18:19, Philip Paeps wrote:
On 2019-02-22 10:14:52 (+0900), Marcos Passos wrote:
On Thu, Feb 21, 2019 at 21:55 Philip Paeps <philip@trouble.is> wrote:
On 2019-02-21 16:31:39 (+0900), Ankur Rana wrote:
While doing tzdata upgrade to version 2018f
Note that you should really be upgrading to 2018i, which is the latest version.
java.lang.Exception: Failed while parsing file '/tmp/tz.tmp/asia' on line 1842 'Rule Japan 1948 1951 - Sep Sat>=8 25:00 0 S'
Java is known to be broken with respect to the last ten years or so of changes to the tzdb data format. You'll need to generate "rearguard" format data to feed to the Java updater.
Stephen can confirm it, but I built all versions since 2018 using JSR-310 a few months and the result was correct.
Last I read on the tz mailing list, the Java tzdb parser doesn't like negative SAVE rules or more than 24 hours in a day. Happy to hear that was fixed at last. Thank you for pointing that out.
Marcos didn't say whether it was vanguard, standard, or rearguard format data that was used for 2018. As JSR 310 appears to be unchanged since 2014, until Marcos or Stephen explicitly states otherwise, it would be safer to continue to assume that rearguard format data is required.
-- 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.
There are three different parsers I've been involved with: - Joda-Time - ThreeTen-Backport - JSR-310 as integrated into Java 8 and later At present, Joda-Time can handle the latest TZDB format, dynamically reverting the breaking changes made to the file format. The approach taken is imperfect and will no doubt break again at some point in the future. https://github.com/JodaOrg/joda-time/commit/c5c681c91c74a508e67911e0af498084... ThreeTen-Backport has a fix for 25:00 mentioned above: https://www.threeten.org/threetenbp/changes-report.html#a1.3.8 I believe the Java 8 parser requires the rearguard format, but it is not controlled by me anymore. https://bugs.openjdk.java.net/browse/JDK-8195595 Stephen On Fri, 22 Feb 2019 at 01:15, Marcos Passos <marcospassos.com@gmail.com> wrote:
Stephen can confirm it, but I built all versions since 2018 using JSR-310 a few months and the result was correct.
On Thu, Feb 21, 2019 at 21:55 Philip Paeps <philip@trouble.is> wrote:
On 2019-02-21 16:31:39 (+0900), Ankur Rana wrote:
While doing tzdata upgrade to version 2018f
Note that you should really be upgrading to 2018i, which is the latest version.
java.lang.Exception: Failed while parsing file '/tmp/tz.tmp/asia' on line 1842 'Rule Japan 1948 1951 - Sep Sat>=8 25:00 0 S'
Java is known to be broken with respect to the last ten years or so of changes to the tzdb data format. You'll need to generate "rearguard" format data to feed to the Java updater.
Paul also helpfully provides rearguard tarballs on his webpage https://web.cs.ucla.edu/~eggert/tz/release/.
You can easily generate those yourself by running make rearguard_tarballs on the distribution from iana.org.
To avoid any reoccurrence of same, would it be possible to prevent the tzdata version 2018f from downloading on iana site?
It seems silly to pull one release from an archive going back to 1993 because one third-party implementation (even if it's a popular one) cannot cope with the data format.
Philip
-- Philip Paeps Senior Reality Engineer Ministry of Information
So tzupdater still requires to make or use the rearguard tarball as before. On 2019-02-22 08:46, Stephen Colebourne wrote:
There are three different parsers I've been involved with:
- Joda-Time - ThreeTen-Backport - JSR-310 as integrated into Java 8 and later
At present, Joda-Time can handle the latest TZDB format, dynamically reverting the breaking changes made to the file format. The approach taken is imperfect and will no doubt break again at some point in the future. https://github.com/JodaOrg/joda-time/commit/c5c681c91c74a508e67911e0af498084...
ThreeTen-Backport has a fix for 25:00 mentioned above: https://www.threeten.org/threetenbp/changes-report.html#a1.3.8
I believe the Java 8 parser requires the rearguard format, but it is not controlled by me anymore. https://bugs.openjdk.java.net/browse/JDK-8195595
Stephen
On Fri, 22 Feb 2019 at 01:15, Marcos Passos <marcospassos.com@gmail.com> wrote:
Stephen can confirm it, but I built all versions since 2018 using JSR-310 a few months and the result was correct.
On Thu, Feb 21, 2019 at 21:55 Philip Paeps <philip@trouble.is> wrote:
On 2019-02-21 16:31:39 (+0900), Ankur Rana wrote:
While doing tzdata upgrade to version 2018f
Note that you should really be upgrading to 2018i, which is the latest version.
java.lang.Exception: Failed while parsing file '/tmp/tz.tmp/asia' on line 1842 'Rule Japan 1948 1951 - Sep Sat>=8 25:00 0 S'
Java is known to be broken with respect to the last ten years or so of changes to the tzdb data format. You'll need to generate "rearguard" format data to feed to the Java updater.
Paul also helpfully provides rearguard tarballs on his webpage https://web.cs.ucla.edu/~eggert/tz/release/.
You can easily generate those yourself by running make rearguard_tarballs on the distribution from iana.org.
To avoid any reoccurrence of same, would it be possible to prevent the tzdata version 2018f from downloading on iana site?
It seems silly to pull one release from an archive going back to 1993 because one third-party implementation (even if it's a popular one) cannot cope with the data format.
Philip
-- Philip Paeps Senior Reality Engineer Ministry of Information
-- 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 2/22/19 9:56 AM, Brian Inglis wrote:
So tzupdater still requires to make or use the rearguard tarball as before.
Actually, I'm seeing reports that it works with the current main-format tarball. For what it's worth, I just now tried Oracle's current TZUpdater, version 2.2.0 <https://www.oracle.com/technetwork/java/javase/tzupdater-readme-136440.html> dated August, and it didn't error out with the current main-format tarball (it merely issued warnings). That being said, I lack installation privileges on the Solaris host I tried this on, and so didn't check what happens when you use the resulting installation.
So tzupdater still requires to make or use the rearguard tarball as before. On 2019-02-22 08:46, Stephen Colebourne wrote:
There are three different parsers I've been involved with:
- Joda-Time - ThreeTen-Backport - JSR-310 as integrated into Java 8 and later
At present, Joda-Time can handle the latest TZDB format, dynamically reverting the breaking changes made to the file format. The approach taken is imperfect and will no doubt break again at some point in the future. https://github.com/JodaOrg/joda-time/commit/c5c681c91c74a508e67911e0af498084...
ThreeTen-Backport has a fix for 25:00 mentioned above: https://www.threeten.org/threetenbp/changes-report.html#a1.3.8
I believe the Java 8 parser requires the rearguard format, but it is not controlled by me anymore. https://bugs.openjdk.java.net/browse/JDK-8195595
Stephen
On Fri, 22 Feb 2019 at 01:15, Marcos Passos <marcospassos.com@gmail.com> wrote:
Stephen can confirm it, but I built all versions since 2018 using JSR-310 a few months and the result was correct.
On Thu, Feb 21, 2019 at 21:55 Philip Paeps <philip@trouble.is> wrote:
On 2019-02-21 16:31:39 (+0900), Ankur Rana wrote:
While doing tzdata upgrade to version 2018f
Note that you should really be upgrading to 2018i, which is the latest version.
java.lang.Exception: Failed while parsing file '/tmp/tz.tmp/asia' on line 1842 'Rule Japan 1948 1951 - Sep Sat>=8 25:00 0 S'
Java is known to be broken with respect to the last ten years or so of changes to the tzdb data format. You'll need to generate "rearguard" format data to feed to the Java updater.
Paul also helpfully provides rearguard tarballs on his webpage https://web.cs.ucla.edu/~eggert/tz/release/.
You can easily generate those yourself by running make rearguard_tarballs on the distribution from iana.org.
To avoid any reoccurrence of same, would it be possible to prevent the tzdata version 2018f from downloading on iana site?
It seems silly to pull one release from an archive going back to 1993 because one third-party implementation (even if it's a popular one) cannot cope with the data format.
Philip
-- Philip Paeps Senior Reality Engineer Ministry of Information
-- 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. -- 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.
* Stephen Colebourne:
I believe the Java 8 parser requires the rearguard format, but it is not controlled by me anymore. https://bugs.openjdk.java.net/browse/JDK-8195595
Note that the more thorny issue is this one: <https://bugs.openjdk.java.net/browse/JDK-8212684> <https://bugs.openjdk.java.net/browse/JDK-8212970> The current API follows POSIX and its requirements on hourly offsets, and tzdata is no longer compatible with the POSIX specification of TZ rules. Thanks, Florian
On 2/22/19 10:01 AM, Florian Weimer wrote:
Note that the more thorny issue is this one:
<https://bugs.openjdk.java.net/browse/JDK-8212684> <https://bugs.openjdk.java.net/browse/JDK-8212970>
The current API follows POSIX and its requirements on hourly offsets, and tzdata is no longer compatible with the POSIX specification of TZ rules.
As far as I know this is currently an issue only with America/Godthab, Asia/Jerusalem, and Pacific/Fiji, all of which use rules for future timestamps that cannot be expressed using POSIX TZ strings. I don't know what the various TZUpdater/JDK combinations do with this. This issue with non-POSIX TZ strings has been present since tzcode 2013e. It is not directly connected to the more-recent kerfuffles about negative DST (as POSIX allows negative DST) and about a 25:00 time-of-day (as the current data's 25:00 can be simulated with a POSIX TZ string). Here are the TZ values in question. They use Internet RFC 8653 section 3.3.1's extensions to POSIX TZ strings. America/Godthab <-03>3<-02>,M3.5.0/-2,M10.5.0/-1 Asia/Jerusalem IST-2IDT,M3.4.4/26,M10.5.0 Pacific/Fiji <+12>-12<+13>,M11.1.0,M1.2.2/123
* Paul Eggert:
On 2/22/19 10:01 AM, Florian Weimer wrote:
Note that the more thorny issue is this one:
<https://bugs.openjdk.java.net/browse/JDK-8212684> <https://bugs.openjdk.java.net/browse/JDK-8212970>
The current API follows POSIX and its requirements on hourly offsets, and tzdata is no longer compatible with the POSIX specification of TZ rules.
As far as I know this is currently an issue only with America/Godthab, Asia/Jerusalem, and Pacific/Fiji, all of which use rules for future timestamps that cannot be expressed using POSIX TZ strings. I don't know what the various TZUpdater/JDK combinations do with this.
This issue with non-POSIX TZ strings has been present since tzcode 2013e. It is not directly connected to the more-recent kerfuffles about negative DST (as POSIX allows negative DST) and about a 25:00 time-of-day (as the current data's 25:00 can be simulated with a POSIX TZ string).
Here are the TZ values in question. They use Internet RFC 8653 section 3.3.1's extensions to POSIX TZ strings.
America/Godthab <-03>3<-02>,M3.5.0/-2,M10.5.0/-1 Asia/Jerusalem IST-2IDT,M3.4.4/26,M10.5.0 Pacific/Fiji <+12>-12<+13>,M11.1.0,M1.2.2/123
Ah, I was confused. I mistakenly assumed that the issue with Japan applied to an upcoming time zone changing during the Olympics. But even if it did, it would only be relevant during one year. Since changing DST rules moves a country out of POSIX compliance anyway, the present data (and any one-year exception) isn't a new problem for POSIX. Thanks, Florian
participants (8)
-
Ankur Rana -
Brian Inglis -
Brian Inglis -
Florian Weimer -
Marcos Passos -
Paul Eggert -
Philip Paeps -
Stephen Colebourne