Hi Naoto, Thank you for the response. You are correct. I ran the reproducer against JDK13 and JDK9, and they appear not to differentiate between L and M as long as the input is consistent. I will update the bug and revise the effort accordingly. Thanks!!
-----Original Message----- From: Naoto Sato Sent: Tuesday, July 30, 2019 9:39 PM To: Thejasvi Voniadka <thejasvi.v.vonia...@oracle.com>; core-libs-...@openjdk.java.net; i18n-dev@openjdk.java.net Subject: Re: <i18n dev> RFR: 8160225: java.time.format.DateTimeFormatter issues for month-of-year Hi Thejasvi, M/L does not designate textual nor numeric. Thus I don't think that the suggested documentation fix is correct. Furthermore, although the exception in JDK8 looks like a bug, the test result with JDK9 looks correct to me. The month displayed as "04" is the result of ZonedDateTime.toString() so should not be localized. Naoto On 7/30/19 5:54 AM, Thejasvi Voniadka wrote: > Hi, > > Request your review of this simple change. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8160225 > (java.time.format.DateTimeFormatter issues for month-of-year) > > Description: It is a simple documentation change. The DateTimeFormatter > expects the month format to be represented by "L" for number and "M" for text > (eg: "Jul" may be accepted by a format string "MMM"; "07" may be accepted by > a format string "LL", and so on). However, the documentation lists this > somewhat confusingly: > > "M/L month-of-year number/text 7; 07; Jul; July; J" > > A casual reader may interpret "M" as the numeric representation and "L" as > the textual representation of the month-of-year, whereas the actual behavior > of the API is the other way around. This patch fixes it. > > > Webrev: http://cr.openjdk.java.net/~vagarwal/8160225/webrev.0/ > > > >
