RFR: JDK-8033662 DateTimeFormatter parsing ignores withZone()

[Chris Hegarty]

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

-Chris.

> 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