Bug 1789468 - NullPointerException in ZonedDateTime.parse
Summary: NullPointerException in ZonedDateTime.parse
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: tzdata
Version: 31
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Patsy Griffin
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-01-09 15:58 UTC by Mattias Andersson
Modified: 2020-06-05 16:26 UTC (History)
7 users (show)

Fixed In Version: tzdata-2019c-2.fc30 tzdata-2019c-2.fc31
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-01-31 01:12:44 UTC
Type: Bug


Attachments (Terms of Use)
Reproducer showing Factory with null values (573 bytes, text/plain)
2020-01-09 18:08 UTC, Severin Gehwolf
no flags Details

Description Mattias Andersson 2020-01-09 15:58:31 UTC
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)

Comment 1 Severin Gehwolf 2020-01-09 17:28:55 UTC
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)

Comment 2 Severin Gehwolf 2020-01-09 18:08:52 UTC
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

Comment 3 Severin Gehwolf 2020-01-09 18:21:59 UTC
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.

Comment 4 Severin Gehwolf 2020-01-09 18:25:08 UTC
Patsy: Would you have any input on this issue? It looks like addition of the factory zone in 2019c caused this.

Comment 5 Severin Gehwolf 2020-01-09 19:34:18 UTC
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)

Comment 6 Patsy Griffin 2020-01-10 16:21:32 UTC
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

Comment 7 Severin Gehwolf 2020-01-10 16:41:43 UTC
(In reply to Patsy Franklin from comment #6)
> I will do an update using your patch ASAP.

Thank you!

Comment 8 Fedora Update System 2020-01-20 14:11:05 UTC
FEDORA-2020-51e892a900 has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2020-51e892a900

Comment 9 Fedora Update System 2020-01-20 14:12:42 UTC
FEDORA-2020-668210b3e1 has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2020-668210b3e1

Comment 10 Fedora Update System 2020-01-21 00:52:38 UTC
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

Comment 11 Fedora Update System 2020-01-21 03:53:27 UTC
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

Comment 12 Fedora Update System 2020-01-31 01:12:44 UTC
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.

Comment 13 Fedora Update System 2020-01-31 02:01:04 UTC
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.

Comment 14 Jon McKenzie 2020-05-18 13:51:44 UTC
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

Comment 15 Patsy Griffin 2020-05-18 16:42:14 UTC
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

Comment 16 Jon McKenzie 2020-06-05 16:14:34 UTC
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

Comment 17 Patsy Griffin 2020-06-05 16:26:53 UTC
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


Note You need to log in before you can comment on or make changes to this bug.