RFR: JDK-8033662 DateTimeFormatter parsing ignores withZone()

Chris Hegarty chris.hegarty at oracle.com
Thu Mar 20 19:06:57 UTC 2014

The changes look ok to me Stephen. I defer to others for the handling of the test/TCK changes.


> On 20 Mar 2014, at 18:24, Stephen Colebourne <scolebourne at joda.org> wrote:
> Hi there,
> It would be great if I could get a review please.
> The patch is viewable in plain text at JIRA (for IP reasons):
> https://bugs.openjdk.java.net/secure/attachment/19216/ParseWithZone.patch
> The same patch is viewable in a nice format at GitHub
> https://gist.github.com/jodastephen/9505761
> This really needs to make 8u20 IMO, so I need to get it into jdk9 first
> thanks
> Stephen
>> On 12 March 2014 12:29, Stephen Colebourne <scolebourne at joda.org> wrote:
>> This is a request for review of this bug:
>> https://bugs.openjdk.java.net/browse/JDK-8033662
>> and the duplicate:
>> https://bugs.openjdk.java.net/browse/JDK-8033659
>> The javadoc of the method java.time.format.DateTimeFormatter::withZone says:
>> "If no zone has been parsed, then this override zone will be included
>> in the result of the parse where it can be used to build instants and
>> date-times."
>> However, the implementation doesn't obey this.
>> This is a very unfortunate bug that makes some date-time parsing a lot harder.
>> A second related bug in an egde case - not properly handling a
>> ChronoZonedDateTime from TemporalField.resolve - is also tested for
>> and fixed.
>> Proposed patch:
>> https://gist.github.com/jodastephen/9505761
>> The patch includes no spec changes.
>> The patch includes new and refactored TCK tests. The new tests for
>> withZone() and withChronology() are based on the spec.
>> I need a reviewer and a committer please.
>> thanks

More information about the core-libs-dev mailing list