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, SignStyle.NORMAL) * 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. Stephen On 26 April 2016 at 12:48, nadeesh tv <nadeesh...@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 >