<i18n dev> RFR: 8160225: java.time.format.DateTimeFormatter issues for month-of-year

[Thejasvi Voniadka]

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.voniadka at oracle.com>; core-libs-dev at openjdk.java.net; i18n-dev at 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/
> 
> 
> 
>