Skip to content

Conversation

@WaterWhisperer
Copy link

@WaterWhisperer WaterWhisperer commented Oct 19, 2025

related issue #6603

@CLAassistant
Copy link

CLAassistant commented Oct 19, 2025

CLA assistant check
All committers have signed the CLA.

@sffc
Copy link
Member

sffc commented Oct 19, 2025

Thank you for the contribution! I'll leave comments soon. In the meantime I triggered the continuous integration.

@WaterWhisperer
Copy link
Author

@sffc Thanks for the review!

sffc
sffc previously approved these changes Oct 20, 2025
Copy link
Member

@sffc sffc left a comment

Choose a reason for hiding this comment

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

Thanks!

@robertbastian
Copy link
Member

Are we fine making this stable?

this PR does not fix the issue as it only exposes AM/PM, no month or day names

Manishearth
Manishearth previously approved these changes Oct 21, 2025
@Manishearth
Copy link
Member

I'm okay with this API as written. It doesn't seem like it fixes the whole issue though, so I'm wondering if we should wait to merge this until after 2.1.

@WaterWhisperer
Copy link
Author

Thanks for the reviews!

I see the discussion about this not fully addressing #6603. The original issue includes getters for weekdays, month names, and era codes as well.

Should I extend this PR to include those, or handle them in separate PRs?

Happy to work on whichever approach is most helpful. Thanks for your patience with a first-time contributor! 😊

@Manishearth
Copy link
Member

@WaterWhisperer Either is fine: the discussion is about merging this before ICU4X 2.1, releasing in the next few weeks. Once that release happens we're more open to merging this as-is.

I think having all of the methods in the same PR is a good idea anyway. We already have alignment on the general approach.

@WaterWhisperer
Copy link
Author

@WaterWhisperer Either is fine: the discussion is about merging this before ICU4X 2.1, releasing in the next few weeks. Once that release happens we're more open to merging this as-is.

I think having all of the methods in the same PR is a good idea anyway. We already have alignment on the general approach.

Understood, thanks for the guidance!

@WaterWhisperer WaterWhisperer dismissed stale reviews from Manishearth and sffc via 1a28516 October 23, 2025 06:02
/// None
/// );
/// ```
pub fn get_month(&self, month_code: MonthCode, length: MonthNameLength) -> Option<&str> {
Copy link
Member

Choose a reason for hiding this comment

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

issue: MonthCode is probably not the type we want to use here. #7149

Copy link
Member

Choose a reason for hiding this comment

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

Note: We want to accept a "formatting" month, which differentiates between Adar and Adar II.

/// None
/// );
/// ```
pub fn get_era(&self, era_year: &EraYear, length: YearNameLength) -> Option<&str> {
Copy link
Member

Choose a reason for hiding this comment

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

issue: clients won't know how to construct an EraYear correctly, so this method is only useful for eras returned by a Date.

do we want to add support for accept era codes (like ce) here? we would need some kind of integration with icu::calendar.

@WaterWhisperer
Copy link
Author

Thank you @robertbastian for the review and feedback!

I completely understand both concerns you raised:

  1. MonthCode issue: I see issue Introduce a validated Month type #7149, and I agree that we need a validated Month type. The current MonthCode requires handling invalid syntax in every API.

  2. EraYear issue: You're right that clients won't know how to properly construct an EraYear. Using era code strings (like "ce") would be much more user-friendly.

Therefore, I've decided to keep only get_am and get_pm getters in this PR. I've reverted the other getters (weekday, month, era) and rebased the branch onto the latest main.

I'll try to implement the other getters after these issues are resolved:

  • get_month: waiting for Introduce a validated Month type #7149
  • get_era: needs API redesign to accept era code strings
  • get_weekday: the API looks fine, but to keep this PR focused, I'll save it for later

This way, this PR focuses on the most basic AM/PM getter functionality from issue #6603, and the remaining getters can be improved incrementally in future PRs.

Please let me know if this approach works for you!

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.

5 participants