Skip to content
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

ICU-23006 Fix Chinese Calendar getActualMaximize #3348

Merged
merged 1 commit into from
Jan 29, 2025

Conversation

FrankYFTang
Copy link
Contributor

@FrankYFTang FrankYFTang commented Jan 25, 2025

Read the IS_LEAP_MONTH field correctly while calling getActualMaximize.

Chinese Calendar need to read additional IS_LEAP_MONTH field while calculate the start and length of month, make the value read from the out most calls and passed into function parameter.

Checklist

  • Required: Issue filed: ICU-23006
  • Required: The PR title must be prefixed with a JIRA Issue number. Example: "ICU-1234 Fix xyz"
  • Required: Each commit message must be prefixed with a JIRA Issue number. Example: "ICU-1234 Fix xyz"
  • Issue accepted (done by Technical Committee after discussion)
  • Tests included, if applicable
  • API docs and/or User Guide docs changed or added, if applicable

@FrankYFTang FrankYFTang changed the title ICU-23006 Fix Chinese getActualMaximize ICU-23006 Fix Chinese Calendar getActualMaximize Jan 25, 2025
richgillam
richgillam previously approved these changes Jan 25, 2025
Copy link
Contributor

@richgillam richgillam left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks fine, I think, and I think I'm okay with you checking in as-is, so I went ahead and approved, but I do have some questions you might want to consider. Most of those questions apply to both the C++ and Java versions of your change, but I didn't repeat them on the Java code.

return handleGetMonthLengthWithLeap(extendedYear, month, isLeapMonth, status);
}

int32_t ChineseCalendar::handleGetMonthLengthWithLeap(int32_t extendedYear, int32_t month, bool leap, UErrorCode& status) const {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it really worth it to split handleGetMonthLength() into two functions like this? Wouldn't it be easier to just make the change inside handleGetMonthLength()?

@@ -333,6 +338,14 @@ struct MonthInfo computeMonthInfo(
* @stable ICU 2.8
*/
int64_t ChineseCalendar::handleComputeMonthStart(int32_t eyear, int32_t month, UBool useMonth, UErrorCode& status) const {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same question here: Is it really worth it to split handleComputeMonthStart() into two functions like this?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is necessary because we cannot change the signature of handleComputeMonthStart since it is defined by the superclass but we need to pass in the leap information separately to avoid infinity recusion

int32_t year = cal->get(UCAL_EXTENDED_YEAR, status);
int32_t month = cal->get(UCAL_MONTH, status);
bool leap = cal->get(UCAL_IS_LEAP_MONTH, status) != 0;
return handleGetMonthLengthWithLeap(year, month, leap, status);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm guessing this is a partial answer to my question is here, but if you just left handleGetMonthLength() as one function and updated it to handle the leap year, couldn't you just call it here (it'd then be getting the UCAL_IS_LEAP_MONTH field instead of getting it here).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The problem is one usage need to use get (to force the calculation of all fields) and the other need to use internalGet (to avoid infinity recursion) and I cannot change the function signature (because it is defined in the base class as a protected method for all subclass of Calendar). The tricky part of this fix is it is very easy to get into infinity recursion

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay. Thanks for the explanation.

icu4c/source/test/intltest/caltest.cpp Show resolved Hide resolved
@markusicu
Copy link
Member

rslgtm, leaving it to you two -- tnx!

@FrankYFTang
Copy link
Contributor Author

PTAL

Copy link
Contributor

@richgillam richgillam left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for your answers to my questions. I'm convinced.

@jira-pull-request-webhook
Copy link

Hooray! The files in the branch are the same across the force-push. 😃

~ Your Friendly Jira-GitHub PR Checker Bot

@markusicu
Copy link
Member

tests pass -- ready to merge?

@FrankYFTang FrankYFTang merged commit 7153a3d into unicode-org:main Jan 29, 2025
101 checks passed
@FrankYFTang FrankYFTang deleted the ICU-23006-GetActual branch January 29, 2025 00:34
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants