-
Notifications
You must be signed in to change notification settings - Fork 6.1k
8358819: The first year is not displayed correctly in Japanese Calendar #25732
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
👋 Welcome back naoto! A progress list of the required criteria for merging this PR into |
@naotoj This change now passes all automated pre-integration checks. ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details. After integration, the commit message for the final commit will be:
You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed. At the time when this comment was updated there had been 25 new commits pushed to the
As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details. ➡️ To integrate this PR with the above commit message to the |
/label remove build |
@naotoj |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK, I think I understand the general idea. Japanese Imperial Calendar only returns 元 for first year display name when the style is LONG.
// "GanNen" is supported only in the LONG style.
if (field == YEAR
&& (getBaseStyle(style) != LONG || fieldValue != 1 || get(ERA) == 0)) {
return null;
}
Thus, when SimpleDateFormat
s rely on the underlying Japanese Calendar, they fetch incorrect results since their CLDR pattern defaults to "y" for LONG and FULL, unlike COMPAT which was "yyyy".
So we are updating the CLDRConverter to adapt the old COMPAT style pattern: "yyyy" when using Japanese calendar for LONG or FULL SimpleDateFormat
patterns, such that it can replicate the old "gannen" style which emits the 元.
Yes, that’s correct. The patterns used in CLDR, SimpleDateFormat, and DateTimeFormatterBuilder are similar, but there are some differences that can be quite a pain. CLDRConverter tries to handle these differences, but I don’t think it’s entirely accurate. This case falls into that category. |
Thanks for the reviews! |
1 similar comment
Thanks for the reviews! |
Going to push as commit 9982995.
Your commit was automatically rebased without conflicts. |
@naotoj The command |
This regression was introduced by the removal of the COMPAT locale provider, which partially broke support for the first year in the Japanese calendar. In the Japanese calendar system, the first year of an era should be formatted using the character "元" rather than the numeral "1". The issue arises from a difference in how pattern character lengths are interpreted between CLDR and SimpleDateFormat. The existing
JapaneseEraNameTest
has been updated to cover this fix.Progress
Issue
Reviewers
Reviewing
Using
git
Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/25732/head:pull/25732
$ git checkout pull/25732
Update a local copy of the PR:
$ git checkout pull/25732
$ git pull https://git.openjdk.org/jdk.git pull/25732/head
Using Skara CLI tools
Checkout this PR locally:
$ git pr checkout 25732
View PR using the GUI difftool:
$ git pr show -t 25732
Using diff file
Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/25732.diff
Using Webrev
Link to Webrev Comment