JDK-8032051 : "ZonedDateTime" class "parse" method fails with short time zone offset ("+01")
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.time
  • Affected Version: 8
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: os_x
  • Submitted: 2014-01-17
  • Updated: 2018-09-04
  • Resolved: 2016-03-21
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 9
9 b112Fixed
Related Reports
Relates :  
Description
FULL PRODUCT VERSION :
java version "1.8.0-ea"
Java(TM) SE Runtime Environment (build 1.8.0-ea-b123)
Java HotSpot(TM) 64-Bit Server VM (build 25.0-b65, mixed mode)


ADDITIONAL OS VERSION INFORMATION :
Darwin Brainys-Mac-mini.local 13.0.0 Darwin Kernel Version 13.0.0: Thu Sep 19 22:22:27 PDT 2013; root:xnu-2422.1.72~6/RELEASE_X86_64 x86_64

A DESCRIPTION OF THE PROBLEM :
For date-time string formats both ISO 8601 and RFC 3339 allow either a long time zone offset including a colon and minutes like this: +01:00
_and_ they allow a shorter offset without the colon and minutes like this: +01

The "ZonedDateTime" class included in Java 8's new java.time.* classes is documented as parsing ISO 8601-like strings. While true of the longer time zone offsets, the shorter offsets cause the class to throw a DateTimeParseException, like this:

java.time.format.DateTimeParseException: Text '2013-12-11T21:25:04.800842+01' could not be parsed at index 26

Here is some demonstration source code???

        String x = "2013-12-11T21:25:04.800842+01:00";
        String y = "2013-12-11T21:25:04.800842+01";
        
        ZonedDateTime zonedDateTime_x = ZonedDateTime.parse( x );  // Succeeds.
        ZonedDateTime zonedDateTime_y = ZonedDateTime.parse( y );  // Fails.



STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Simply run these 4 lines of code.

        String x = "2013-12-11T21:25:04.800842+01:00";
        String y = "2013-12-11T21:25:04.800842+01";
        
        ZonedDateTime zonedDateTime_x = ZonedDateTime.parse( x );  // Succeeds.
        ZonedDateTime zonedDateTime_y = ZonedDateTime.parse( y );  // Fails.


EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Both calls to "parse" should succeed.
ACTUAL -
The second call to "parse" throws an exception like this one:

java.time.format.DateTimeParseException: Text '2013-12-11T21:25:04.800842+01' could not be parsed at index 26

ERROR MESSAGES/STACK TRACES THAT OCCUR :
java.time.format.DateTimeParseException: Text '2013-12-11T21:25:04.800842+01' could not be parsed at index 26

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
String x = "2013-12-11T21:25:04.800842+01:00";
String y = "2013-12-11T21:25:04.800842+01";

ZonedDateTime zonedDateTime_x = ZonedDateTime.parse( x );  // Succeeds.
ZonedDateTime zonedDateTime_y = ZonedDateTime.parse( y );  // Fails.

---------- END SOURCE ----------
Comments
http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-February/038814.html
11-02-2016

Those would have no meaning. The lower case part means "optional" here, and once you have optional minutes, the seconds must also be optional.
13-11-2015

@Stephen - Should not we add "+HHmmSS" and "+HH:mm:SS" also?
13-11-2015

Step one in any fix to this area is adding more patterns to `DateTimeFormatterBuilder.appendOffset(String,String)`. The missing ones are "+HHmmss" and "+HH:mm:ss". Its a pity that the got missed out in Java 8, but I can see no reason not to add them in Java 9. I agree that the `DateTimeFormatterBuilder.appendOffsetId()` method cannot be changed and must return "+HH:MM:ss". What could be done is to make the OffsetIdPrinterParser class aware of the lenient parser setting. The parsing could have logic added that treats each part of the pattern beyond hours as optional if in lenient parsing mode. Alternatively. a new `DateTimeFormatterBuilder.appendOffset(String,String,String)` method could be added with one pattern for formatting and a different pattern for parsing.
30-10-2015

The ISO 8701 spec and RFC 3339 specify offsets as HH[:MM] with the minutes and delimiter to be optional. The DateTimeFormatterBuilder.appendOffsetId uses a formatter HH:MM:ss in which only the seconds are optional. Since compatibility is an issue it is not possible to change the appended formatter to use the pattern +HH:mm. Note that the ZoneOffset.parse() method accepts additional patterns including those that make the delimiters optional. An additional pattern ("+HH[[[:]mm][[:]ss]]") could be added to the OffsetIdPrinterParser to handle both issues. Though it might be simpler to write it as "+HH:mm:ss" and special case to make the delimiters optional. Then the appendOffsetId method could be modified to use the new pattern.
30-10-2015

ZonedDateTIme.parse uses DateTimeFormat ISO_ZONED_DATE_TIME which in turn includes ISO_OFFSET_DATE_TIME which uses appendZoneId. DateTimeFormatterBuilder.appendOffsetId uses a fixed format for parsing numeric ZoneOffsets. "+HH:MM:ss".
22-10-2015

Release team: Approved for deferral.
21-01-2014

SQE is okay for defer
20-01-2014

Roger - it if minor then will you adjust the priority. I spotted the issue in webbugs as java.util bug and moved to core-libs/java.time as P2 so that it would get the right attention (I didn't look at it closely to compute the right priority).
18-01-2014

This issue is a minor implementation issue that can be fixed in an update release.
17-01-2014