Skip to content

Add Iran's Hijri implementation #6474

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

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

Conversation

ebraminio
Copy link
Contributor

This tries to implement what historically till present observed in Iran with Islamic calendar. This uses the data gathered in https://github.com/roozbehp/qamari

Related to #6336

@CLAassistant
Copy link

CLAassistant commented Apr 19, 2025

CLA assistant check
All committers have signed the CLA.

@ebraminio ebraminio force-pushed the main branch 6 times, most recently from 7f31be8 to 5e76726 Compare April 20, 2025 21:41
@ebraminio ebraminio marked this pull request as ready for review April 20, 2025 21:48
@ebraminio ebraminio marked this pull request as draft April 20, 2025 22:02
@ebraminio ebraminio changed the title Add Qamari implementation Add Iran's Hijri implementation Apr 20, 2025
@ebraminio ebraminio force-pushed the main branch 2 times, most recently from 031dac8 to f710466 Compare April 20, 2025 22:52
@Manishearth
Copy link
Member

Ooh, thank you for doing this work! I'll try and have a look when I have time.

We may want to keep it out of the default anycalendar set for now.

Copy link
Member

@Manishearth Manishearth left a comment

Choose a reason for hiding this comment

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

Overall the implementation looks good.

Some general questions for @robertbastian and @sffc (background: this is a data-driven calendar that falls back to tabular islamic)

  • In general we seem to be fine with having non-Any calendar implementations to this crate. I assume we're okay with adding this one? Naming thoughts?
  • We should figure out criteria by which this gets added to Any. We'll need a BCP47 tag probably. And some agreement about shipping the data by default.
  • Code structure wise: should this data be living in calendrical_calculations?
  • Code structure wise: should we clean up the hijri module? It's getting big.

I'm going to suggest we hold off on merging this until 2.0, though I'm happy to have it merged as a private implementation til then.

@sffc
Copy link
Member

sffc commented Apr 24, 2025

Agreed that we should start by landing this in the same way as JapaneseExtended and HijriSimulated (available in icu_calendar but not included in DateTimeFormatter, but potentially formattable with FixedCalendarDateTimeFormatter). Also @hsivonen.

Copy link
Member

@Manishearth Manishearth left a comment

Choose a reason for hiding this comment

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

I think this is overall a good idea. We should probably wait past 2.0 to merge this, and we should figure out what is involved in getting a BCP47 id for this.

@ebraminio ebraminio marked this pull request as ready for review April 25, 2025 06:49
Manishearth added a commit that referenced this pull request Apr 30, 2025
ebraminio added a commit to ebraminio/icu4x that referenced this pull request Apr 30, 2025
ebraminio added a commit to ebraminio/icu4x that referenced this pull request Apr 30, 2025
ebraminio added a commit to ebraminio/icu4x that referenced this pull request Apr 30, 2025
@ebraminio ebraminio force-pushed the main branch 2 times, most recently from 8d781b8 to ff7d362 Compare April 30, 2025 08:43
ebraminio added a commit to ebraminio/icu4x that referenced this pull request May 6, 2025
@sffc sffc added the discuss Discuss at a future ICU4X-SC meeting label May 6, 2025
@robertbastian
Copy link
Member

  • This is an observational calendar, and the data in this PR is only up to today.
    • We should use the data loading infrastructure to support updates
    • We should probably add some mechanism that tells users that results for 2026 are subject to change. Something like Calendar::is_stable(RataDie)
  • The code is generic Hijri, only the data is Iran-specific. We should probably call the type HijriObservational and have different constructors for it

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
discuss Discuss at a future ICU4X-SC meeting
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants