Hi Stephen,
Given the fact that the parser context is no longer public, the parsed from the
formatter is either unresolved or resolved, just wonder if we really need those
"effective" chrono and zone fields in Parsed. It appears perfect for me to
simply
keep these info inside the parser context and return the unresolved and resolved
based on the formatter's request, for example
http://cr.openjdk.java.net/~sherman/8033662/webrev2/
-Sherman
On 03/20/2014 11:24 AM, Stephen Colebourne 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<scolebou...@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
