RFR:JDK-8079628:java.time: DateTimeFormatter containing "DD" fails on 3-digit day-of-year value

Stephen Colebourne scolebourne at joda.org
Tue Apr 26 12:12:37 UTC 2016

This change introduces inconsistencies and problems. For example, it
will parse up to 19 digits for "D" but only up to 2 digits for "d".
The following would be better:

     *    D       1      appendValue(ChronoField.DAY_OF_YEAR)
     *    DD      2      appendValue(ChronoField.DAY_OF_YEAR, 2, 3,
     *    DDD     3      appendValue(ChronoField.DAY_OF_YEAR, 3)

This limits the accepted input to 3 digits, which is quite sufficient
here. It is also clearer for the common "D" and "DDD" cases.

Note that a test case needs to cover adjacent value parsing for
day-of-year. This pattern "yyyyDDD" should be tested and work. With
the webrev changes, it will not work as adjacent value parsing mode
will not be triggered.

(The change will alter the meaning of "yyyyDD" but no-one should be
using that anyway as it is broken, only working for the first 99 days
of the year.)

The code in TCKDateTimeFormatterBuilder needs a blank line after the
new methods.


On 26 April 2016 at 12:48, nadeesh tv <nadeesh.tv at oracle.com> wrote:
> Hi all,
> Please  review a fix for
> Bug ID -   https://bugs.openjdk.java.net/browse/JDK-8079628
> Issue -  Pattern 'D' is not implemented as intended by CLDR
> Solution - Changed the definition of 'D' to D..D 1..3
> appendValue(ChronoField.DAY_OF_YEAR, n, 19, SignStyle.NORMAL)
> Webrev -  http://cr.openjdk.java.net/~ntv/8079628/webrev.00/
> --
> Thanks and Regards,
> Nadeesh TV

More information about the core-libs-dev mailing list