RFR:JDK-8031085:DateTimeFormatter won't parse dates with custom format "yyyyMMddHHmmssSSS"

Stephen Colebourne scolebourne at joda.org
Sun Apr 17 21:33:22 UTC 2016


The updated spec at line 670 is not clear - the adjacent parsing mode
only applies when in strict mode. Suggest a new sentence before the
lenient mode one: "In strict mode, if the minimum and maximum widths
are equal and there is no decimal point then the parser will
participate in adjacent value parsing, see {@code
appendValue(java.time.temporal.TemporalField, int)}.

Line 2968 is missing a blank line

Line 3001 does not need == true on isStrict() == true

Perhaps line 3004 should return false? I'm not sure what is gained by
calling super.

The changes to the test cases look wrong.

test_adjacent_lenient_fractionFollows_2digit() and
test_adjacent_lenient_fractionFollows_0digit() should not have
changed, as the nano-of-second parsing is in lenient mode, and thus
should still parse from zero to nine digits.

thanks
Stephen


On 13 April 2016 at 21:46, nadeesh tv <nadeesh.tv at oracle.com> wrote:
> HI all,
>
> BUG ID : https://bugs.openjdk.java.net/browse/JDK-8031085
>
> Webrev : http://cr.openjdk.java.net/~ntv/8031085/webrev.00/
>
> Issue - Fractional parts of seconds do not participate in the protocol for
> adjacent value parsing
>
> Solution - Changed the FractionPrinterParser to subclass of
> NumberPrinterParser to make it participate in adjacent value parsing
>
>  2 existing test cases
> TCKDateTimeFormatterBuilder.test_adjacent_lenient_fractionFollows_0digit and
> test_adjacent_lenient_fractionFollows_2digit were failing. Changed them
> accordingly.
>
> --
> Thanks and Regards,
> Nadeesh TV
>



More information about the core-libs-dev mailing list