Skip to content

Conversation

sffc
Copy link
Member

@sffc sffc commented Sep 10, 2025

Proof-of-concept for ICU-23210

Checklist

  • Required: Issue filed: ICU-23210
  • 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

@sffc sffc requested a review from richgillam September 10, 2025 23:12
richgillam
richgillam previously approved these changes Sep 11, 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.

I realized halfway through the review that you're only changing the Java code. I'm guessing you're making it consistent with the C++ code? If so, I'm on board with these changes.

|| (type == MINUTE && (options & MATCH_MINUTE_FIELD_LENGTH)==0)
|| (type == SECOND && (options & MATCH_SECOND_FIELD_LENGTH)==0)) {
adjFieldLen = fieldBuilder.length();
}
Copy link
Contributor

Choose a reason for hiding this comment

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

What's the extra test getting you here? I'm not seeing how that changes the logic, but it must, since the unit-test results are different. What am I missing here?

Copy link
Member Author

Choose a reason for hiding this comment

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

The else if had previously been reachable my hour/minute/second, and it was causing the field widths to revert to the pattern widths. With this change, the else if is no longer reachable on those fields.

Copy link
Contributor

Choose a reason for hiding this comment

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

Ah, that's what I was missing. Thanks for the clarification.

@@ -64,7 +64,7 @@ public void TestC() {
{"zh-TW", "CCCCm", "BBBBhh:mm"},
{"zh-TW", "CCCCCm", "BBBBBh:mm"},
{"zh-TW", "CCCCCCm", "BBBBBhh:mm"},
{"de", "Cm", "HH:mm"},
{"de", "Cm", "H:mm"},
Copy link
Contributor

Choose a reason for hiding this comment

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

I notice you're only changing the Java code. The C++ code already did this?

Copy link
Member Author

@sffc sffc Sep 11, 2025

Choose a reason for hiding this comment

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

I figured I would start in ICU4J and continue to ICU4C once I got alignment. (The PR is Draft and I am seeking feedback.)

Copy link
Contributor

Choose a reason for hiding this comment

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

That's fine, but it means I shouldn't have approved the PR yet. I can't figure out how to take that back without just blocking the PR (which I've always thought was kind of rude), so I'll trust you. :-)

@@ -1344,7 +1344,7 @@ public void TestOptions() {
new TestOptionsItem( "en", "Hmm", "HH:mm", DateTimePatternGenerator.MATCH_NO_OPTIONS ),
new TestOptionsItem( "en", "HHmm", "HH:mm", DateTimePatternGenerator.MATCH_NO_OPTIONS ),
new TestOptionsItem( "en", "hhmm", "h:mm\u202Fa", DateTimePatternGenerator.MATCH_NO_OPTIONS ),
new TestOptionsItem( "en", "Hmm", "HH:mm", DateTimePatternGenerator.MATCH_HOUR_FIELD_LENGTH ),
new TestOptionsItem( "en", "Hmm", "H:mm", DateTimePatternGenerator.MATCH_HOUR_FIELD_LENGTH ),
Copy link
Contributor

Choose a reason for hiding this comment

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

Does this match what the C++ code does? And is there already a test somewhere that shows we still get two digits without MATCH_HOUR_FIELD_LENGTH?

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 like I approved prematurely.

@sffc
Copy link
Member Author

sffc commented Sep 11, 2025

Also please note that I haven't updated all of the ICU4J tests yet. I wanted to ask about a few because @richgillam you recently (1 yr ago) added them in ICU-22669

@sffc sffc dismissed richgillam’s stale review September 11, 2025 01:22

PR not ready to be approved yet

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.

2 participants