Add Iran's Hijri implementation

[ebraminio]

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]

All committers have signed the CLA.

[Manishearth]

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.

[sffc]

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.

[robertbastian]

• 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

[sffc]

Notes from a discussion in the ICU4X Working Group:

• @robertbastian It's observational Hijri.
• @sffc Don't we already support one?
• @robertbastian No, we support a simulated Hijri.
• @sffc Looking here, it appears to do a fallback to Civil Tabular, and it contains data only up through 2024.
• @robertbastian The data needs to be updated regularly, it seems at least every year. The PR was opened in April and it contained data through the Hijri year starting in July 2024; maybe those last few months were a guess?
• @robertbastian We either need to have a mechanism for labeling which dates are approximate, and very regularly ship updates, or we need an API to create one of these with your custom data, and we can do calculations on that. I prefer the latter
• @sffc I agree with having a pluggable API; you can start with your base tabular Hijri calendar, like tbla or civil, and then add custom observations, and then everything else in ICU4X should work, including datetime formatting.
• @robertbastian so, the constructor can take a list of YearInfos and a fallback calendar.
• @sffc I was thinking that HijriTabular could just have this as a built-in feature, but maybe best to keep it separate
• @robertbastian Yeah, the data needs to be allocated
• @sffc How do we encode the data safely? I don't want to end up with 31-day months, for example.
• @robertbastian Picking between long and short months is safe. The data currently there is when a year starts, and whether each month is short or long.
• @robertbastian We could even model Umm al-Qura as this. But then it wouldn't be zero-sized... but internally it could just call the other thing.
• @sffc And then we could have a single type with multiple constructors, based on data tables from different authorities, if we wanted to include more authorities than just Umm al-Qura.

[ebraminio]

Thank you so much for the information, I want to just to comment on one of the points.

The PR was opened in April and it contained data through the Hijri year starting in July 2024; maybe those last few months were a guess?

They are official data published each year by calendar center of Tehran university, this one is from https://calendar.ut.ac.ir/documents/2139738/7092644/Calendar-1404.pdf which is mirrored at https://github.com/persiancal/official-data/blob/master/pdf/1404/Calendar-1404.pdf but sometimes during the year needs to be updated also.

Sorry for not commenting earlier and about the other points as I thought some parts of things brought up are the needed infrastructures that I felt should be done beyond this change. The change, if can happen, will be very useful and worths the hassle I should mention again as many of the public holidays are based on the calendar (though not being the main calendar)

[sffc]

Thanks for sharing the Tehran University data source.

If the authority published the data for at least ~3 years in advance (but ideally 10+ years), then I'd feel okay shipping it in sync with ICU4X/CLDR library updates. For example, we have official data for Umm al-Qura, Chinese, and Dangi each for at least 50 years. If the data is valid for only ~1 year, several issues arise:

1. Devices (phones, computers, smartwatches, ...) get updates rather infrequently. You can see here for example that older Android versions tend to stay around for a long time. If we ship calendar data as part of ICU/ICU4X (and therefore as part of the operating system), those devices won't be in working condition for most of their lifespan.
2. It's very common to interact with a calendar in the future; for example, to perform operations such as "schedule a meeting on this date next year". That's not an operation we can support if the calendar data stops before then.

That's where the idea of having a pluggable-data Hijri comes in. An app that needs to support observational Hijri can load its data from its own data source, and then plug it into ICU4X, and then they can get all the features ICU4X has to offer. I don't think this would actually be very difficult to implement.