IslamicUmmAlQura does not agree with ICU4C and https://www.ummulqura.org.sa/

[hsivonen]

Run

    #[test]
    fn test_feb_26() {
        let iso = Date::try_new_iso(2025, 2, 26).unwrap();
        let islamic = iso.to_calendar(IslamicUmmAlQura::new());
        // Data from https://www.ummulqura.org.sa/
        assert_eq!(islamic.day_of_month().0, 27);
        assert_eq!(islamic.month().ordinal, 8);
        assert_eq!(islamic.year().era_year_or_extended(), 1446);
    }

Actual results:

ICU4X says the day of month is 28. ICU4C and https://www.ummulqura.org.sa/ say 27.

[anba]

This specific case could be related to #5069, because switching to the always calculating calendar gives the expected result. https://github.com/EdReingold/calendar-code2/blob/main/calendar.l also returns 27:

* (saudi-islamic-from-fixed (fixed-from-gregorian (gregorian-date 2025 february 26)))
(1446 8 27)

---

There are cases where KACST reports other results than Reingold. For example December 2, 2024:

* (saudi-islamic-from-fixed (fixed-from-gregorian (gregorian-date 2024 december 2)))
(1446 5 30)

KACST gives Jumada al-Alkhirah (6) 1, 1446 as the converted date.

The fixed date for December 2, 2024 is 739222:

* (fixed-from-gregorian (gregorian-date 2024 december 2))
739222

saudi-islamic-from-fixed first calls saudi-new-month-on-or-before to determine the new moon date:

* (saudi-new-month-on-or-before 739222)
739193

739193 is the start of the fifth month, but per KACST this should have returned 739222:

* (saudi-islamic-from-fixed 739193)
(1446 5 1)

Let's look into saudi-new-month-on-or-before to investigate why Reingold gave a different answer:

* (fixed-from-moment (lunar-phase-at-or-before new 739222))
739221
0.2649154723621905d0
* (- 739222 (fixed-from-moment (lunar-phase-at-or-before new 739222)))
1
* (saudi-criterion 739222)
NIL

So age <= 3, but the Saudi criterion isn't fulfilled and therefore 739222 isn't a valid month start per Reingold. So we need to check saudi-criterion:

* (sunset (1- 739222) mecca)
739221.7364779075d0
* (universal-from-standard 739221.7364779075d0 mecca)
739221.6114779075d0
* (lunar-phase 739221.6114779075d0)
3.988286281883063d0
* (< new 3.988286281883063d0 first-quarter)
T
* (moonlag (1- 739222) mecca)
-1.3811280950903893d-5

Okay, so apparently moonlag isn't larger than zero and therefore the Saudi criterion isn't fulfilled. How many seconds is -1.3811280950903893d-5?

* (* -1.3811280950903893d-5 86400)
-1.1932946741580963d0

So the moon set is a second before the sun set and therefore the criterion isn't fulfilled. This makes me wonder if a single second difference should be ignored?

* (sunset (1- 739222) mecca)
739221.7364779075d0
* (moonset (1- 739222) mecca)
739221.7364640962d0

---

How come that ICU4C agrees with KACST? Do they use different astronomical algorithms? No, they use a hard-coded table for Hijri years 1300-1600 → https://github.com/unicode-org/icu/blob/9cc28a6428c8597cbeb2550867748c0e7ae23246/icu4c/source/i18n/islamcal.cpp#L84-L188. The data itself was requested from KACST, cf. https://unicode-org.atlassian.net/browse/ICU-10695 and https://unicode-org.atlassian.net/browse/ICU-10936.

Maybe ICU4X should also use a hard-coded table for these years to ensure compatibility with KACST? (Assuming only KACST is used as the single source of truth and advancements or postponements from the High Judiciary Council of Saudi Arabia are ignored, see also https://webspace.science.uu.nl/~gent0113/islam/ummalqura_adjust.htm.)