Thanks, Stephen.
On 11/21/17 1:35 AM, Stephen Colebourne wrote:
On 21 November 2017 at 01:45, Naoto Sato <naoto.s...@oracle.com> wrote:
2) `DecimalStyle.ofLocale(Locale)` should use "nu" but does not.
Document it in the javadoc.
Javadoc looks good, but the webrev didn't contain matching code last
time I looked.
I haven't updated the webrev yet, since it will involve new test cases.
I wanted to make sure the direction of the change was correct. Will
update the webrev soon.
3) `DateTimeFormatter.localizedBy(Locale)` should use "ca" to call
`withChronology`, `tz` to call `withZoneId` and `nu` to call
`withDecimalStyle`. This is a change to the CSR.
Besides that "nu" needs to be spec'ed out, isn't calling withXXXX() an
implementation note?
The revised text ends with "Same is true for the "nu" extension.", but
doesn't mention the case where both "tz" and "rg" are present.
Since there is no ZoneId.ofLocale(rg), a region does not designate a
time zone (yet). So there would be no conflict between "tz" and "rg"
extensions.
7) WeekBasedFieldPrinterParser should use "fw"/"rg", which it already
does via WeekFields.of(Locale)
Not sure what this means. Where is the file located?
WeekBasedFieldPrinterParser is an inner class of DateTimeFormatterBuilder
OK, thanks.
10) Consider how localizedBy(Locale) operates.
IIRC, the localizedBy() is added so that withLocale() would behave as it is
now. I think localizedBy() should also have the same effect as withLocale if
the specified locale do not contain any calendar/timezone/numberingSystem
extensions. Otherwise, say localizedBy(Locale.JAPAN) would be no-operation.
OK, I agree. localizedBy(locale) is the same as withLocale(locale)
unless there are "ca", "tz" or "nu", in which case the matching
element is updated.
Good.
Naoto
