<i18n dev> RFR: 8317742: ISO Standard Date Format implementation consistency on DateTimeFormatter and String.format [v5]

Naoto Sato naoto at openjdk.org
Tue Nov 7 13:31:35 UTC 2023


On Tue, 7 Nov 2023 01:31:03 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> j.u.Formatter now prints "%tF" (iso standard date) and the result is incorrect when processing year < 0 or year > 9999
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use DecimalFormatSymbols#getMinusSign

src/java.base/share/classes/java/util/Formatter.java line 4495:

> 4493:                     int year = t.get(ChronoField.YEAR);
> 4494:                     if (year < 0) {
> 4495:                         sb.append(DecimalFormatSymbols.getInstance(l).getMinusSign());

Instead of creating the instance each time, `getMinusSign(Locale)` can be defined, analogous to `getZero(Locale)` so that the cached instance is reused.

test/jdk/java/util/Formatter/BasicDateTime.java line 473:

> 471:                 "%tF",
> 472:                 DecimalFormatSymbols.getInstance(localeEuES).getMinusSign() + "2023-01-13",
> 473:                 LocalDate.of(-2023, 1, 13));

Needs some comments here, otherwise it would be a bit cryptic. Also, "eu-ES" locale using `\u2212` depends on the current CLDR implementation, so you might want to check all locales with  `Locale.availableLocale()`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16033#discussion_r1384355166
PR Review Comment: https://git.openjdk.org/jdk/pull/16033#discussion_r1384915823


More information about the i18n-dev mailing list