Description of problem: I get a NPE in when trying to parse a date with java.time.ZonedDateTime#parse Version-Release number of selected component (if applicable): java --version openjdk 11.0.5 2019-10-15 OpenJDK Runtime Environment 18.9 (build 11.0.5+10) OpenJDK 64-Bit Server VM 18.9 (build 11.0.5+10, mixed mode, sharing) java-11-openjdk-devel.x86_64 1:11.0.5.10-0.fc31 How reproducible: Always Steps to Reproduce: In jshell: 1. import java.time.*; 2. import java.time.format.*; 3. ZonedDateTime.parse("20170505T173000.000Z", DateTimeFormatter.ofPattern("yyyyMMdd'T'HHmmss'.'SSSz")) Actual results: | Exception java.time.format.DateTimeParseException: Text '20170505T173000.000Z' could not be parsed: null | at DateTimeFormatter.createError (DateTimeFormatter.java:2017) | at DateTimeFormatter.parse (DateTimeFormatter.java:1952) | at ZonedDateTime.parse (ZonedDateTime.java:598) | at (#3:1) | Caused by: java.lang.NullPointerException | at DateTimeFormatterBuilder$PrefixTree.prefixLength (DateTimeFormatterBuilder.java:4527) | at DateTimeFormatterBuilder$PrefixTree.add0 (DateTimeFormatterBuilder.java:4396) | at DateTimeFormatterBuilder$PrefixTree.add (DateTimeFormatterBuilder.java:4391) | at DateTimeFormatterBuilder$ZoneTextPrinterParser.getTree (DateTimeFormatterBuilder.java:4138) | at DateTimeFormatterBuilder$ZoneIdPrinterParser.parse (DateTimeFormatterBuilder.java:4249) | at DateTimeFormatterBuilder$CompositePrinterParser.parse (DateTimeFormatterBuilder.java:2370) | at DateTimeFormatter.parseUnresolved0 (DateTimeFormatter.java:2107) | at DateTimeFormatter.parseResolved0 (DateTimeFormatter.java:2036) | at DateTimeFormatter.parse (DateTimeFormatter.java:1948) Expected results: $3 ==> 2017-05-05T17:30Z Additional info: Works with java --version openjdk 11.0.3 2019-04-16 OpenJDK Runtime Environment AdoptOpenJDK (build 11.0.3+7) OpenJDK 64-Bit Server VM AdoptOpenJDK (build 11.0.3+7, mixed mode)
Thanks for the report. This seems to be an issue with the system integration of tzdata as the vanilla JDK 11.0.5+10 build works fine: $ ./openjdk-11.0.5+10/bin/jshell | Welcome to JShell -- Version 11.0.5 | For an introduction type: /help intro jshell> import java.time.*; jshell> import java.time.format.*; jshell> ZonedDateTime.parse("20170505T173000.000Z", DateTimeFormatter.ofPattern("yyyyMMdd'T'HHmmss'.'SSSz")) $3 ==> 2017-05-05T17:30Z jshell> $ ./openjdk-11.0.5+10/bin/java -version openjdk version "11.0.5" 2019-10-15 OpenJDK Runtime Environment 18.9 (build 11.0.5+10) OpenJDK 64-Bit Server VM 18.9 (build 11.0.5+10, mixed mode)
Created attachment 1651046 [details] Reproducer showing Factory with null values Run as (pre: install java-11-openjdk-devel): $ /usr/lib/jvm/java-11-openjdk/bin/javac TimeZoneParsing.java $ /usr/lib/jvm/java-11-openjdk/bin/java TimeZoneParsing
Indeed. Downgrading tzdata{,-java} to 2019a fixes the issue. $ rpm -q tzdata{,-java} tzdata-2019a-1.fc30.noarch tzdata-java-2019a-1.fc30.noarch $ /usr/lib/jvm/java-11-openjdk/bin/jshell | Welcome to JShell -- Version 11.0.5 | For an introduction type: /help intro jshell> import java.time.*; jshell> import java.time.format.*; jshell> ZonedDateTime.parse("20170505T173000.000Z", DateTimeFormatter.ofPattern("yyyyMMdd'T'HHmmss'.'SSSz")) $3 ==> 2017-05-05T17:30Z So what's going on? Running the reproducer from comment 2 after the downgrade we get this output: Factory zone not found! Running the reproducer from comment 2 with 2019c as in all Fedoras we get this output: [Factory, null, null, null, null, null, null] So the addition of the Factory zone broke this. The Java code expects non-null values for other fields in that array. This doesn't seem right. Re-assigning to tzdata owners for input. Note that all working JDK 11 versions don't find the "Factory" zone. The same is true for JDK 8 with 2019c. Not sure why.
Patsy: Would you have any input on this issue? It looks like addition of the factory zone in 2019c caused this.
Proposed patch which seems to work for me: https://src.fedoraproject.org/rpms/tzdata/pull-request/3 $ rpm -q tzdata{,-java} tzdata-2019c-2.fc31.noarch tzdata-java-2019c-2.fc31.noarch $ /usr/lib/jvm/java-11-openjdk/bin/jshell | Welcome to JShell -- Version 11.0.5 | For an introduction type: /help intro jshell> import java.time.*; jshell> import java.time.format.*; jshell> ZonedDateTime.parse("20170505T173000.000Z", DateTimeFormatter.ofPattern("yyyyMMdd'T'HHmmss'.'SSSz")) $3 ==> 2017-05-05T17:30Z $ /usr/lib/jvm/java-11-openjdk/bin/java -version openjdk version "11.0.5" 2019-10-15 OpenJDK Runtime Environment 18.9 (build 11.0.5+10) OpenJDK 64-Bit Server VM 18.9 (build 11.0.5+10, mixed mode, sharing)
Hi Severin, Thanks for reporting this! We recently added the Factory file back in to be more closely match the upstream project. I will do an update using your patch ASAP. Thanks! Patsy
(In reply to Patsy Franklin from comment #6) > I will do an update using your patch ASAP. Thank you!
FEDORA-2020-51e892a900 has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2020-51e892a900
FEDORA-2020-668210b3e1 has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2020-668210b3e1
tzdata-2019c-2.fc30 has been pushed to the Fedora 30 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-668210b3e1
tzdata-2019c-2.fc31 has been pushed to the Fedora 31 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-51e892a900
tzdata-2019c-2.fc30 has been pushed to the Fedora 30 stable repository. If problems still persist, please make note of it in this bug report.
tzdata-2019c-2.fc31 has been pushed to the Fedora 31 stable repository. If problems still persist, please make note of it in this bug report.
I think this bug was re-introduced with the rebase to tzdata 2020a. When I downgrade to the latest tzdata and tzdata-java 2019c my issue is resolved
Jon I'm sorry to hear that you are seeing an issue with tzdata. Looking at the spec files for tzdata-2020a, I see the patch provided in this bz applied and that the Factory zone is not included for tzdata-java as expected. Looking at the tzdata-java-2020a builds, I see that there is no Factory file in tzdata-java-2020a-1.fc33.noarch.rpm. I'm wondering if you are seeing a different issue. Could you please provide more information about the failure you are seeing? Specifically, could you please try this: rpm -qlv tzdata-java-2020a*.rpm | grep Factory Thank you! Patsy
That indeed returns no results, so maybe it's not Factory but some other TZ that's the issue. When I run the jshell reproduction in the original comment I get the same stacktrace. Here are the tz and JDK RPMs I have installed: java-11-openjdk-headless-11.0.7.10-4.el7_8.x86_64 tzdata-2020a-1.el7.noarch tzdata-java-2020a-1.el7.noarch java-11-openjdk-11.0.7.10-4.el7_8.x86_64 java-11-openjdk-devel-11.0.7.10-4.el7_8.x86_64
Hi Jon, I was able to reproduce the failure and believe that what you're seeing may be related to BZ 1837376. Thank again for reporting this! Patsy