Diyanet Variant Not Working in Android - Variant.DIYANET fails with ArithmeticException in time4j-hijri Android 4.8-2021a

[BordoBereli]

Description: The Variant.DIYANET in Time4A's Hijri calendar implementation consistently throws ArithmeticException when trying to convert Gregorian dates to Hijri dates, even for dates that should be within the supported range (post-1921/1340H). This makes it impossible to use the official Turkish Diyanet calendar calculations through Time4A.

Steps to Reproduce

Environment: Time4A Android 4.8-2021a

**Code to reproduce:**

import net.time4j.PlainDate
import net.time4j.calendar.HijriCalendar
import java.time.LocalDate

fun testDiyanetVariant() {
val today = LocalDate.now() // e.g., 2026-02-07
val todayDate = PlainDate.of(today.year, today.monthValue, today.dayOfMonth)

// This always fails:
val hijriDate = todayDate.transform(
    HijriCalendar::class.java, 
    HijriCalendar.Variant.DIYANET
)

}

**Result: Always throws:**

java.lang.ArithmeticException: Cannot transform <19759> to: net.time4j.calendar.HijriCalendar
at net.time4j.engine.Calendrical.transform(Calendrical.java:420)

Expected Behavior:

The Variant.DIYANET should:

Successfully convert Gregorian dates to Hijri dates according to Turkish Diyanet İşleri Başkanlığı's official calendar

Support dates from at least 1921 onwards (which marks 1340H, the typical start of modern calendar calculations)

Provide accurate results for important dates like Ramadan beginnings (e.g., 2026-02-16 should be Şaban 30, not Ramadan 1 as in UMMALQURA)

Actual Behavior:

Always fails with ArithmeticException for any date tested

No successful conversions observed, even for recent dates

No clear documentation on supported date ranges or limitations

Technical Details:

Time4A Version: 4.8-2021a (Android)

Dependencies:

    net.time4j:time4j-android:4.8-2021a

    net.time4j:time4j-hijri:4.8-2021a

Test Environment: Android API 30+, Kotlin 1.8+

Alternative Variants: Variant.UMMALQURA, Variant.ISLAMIC_CIVIL work correctly

Impact:

Turkish developers cannot use Time4A for official Diyanet calendar calculations

Religious applications in Turkey require manual workarounds

Inconsistency between Time4A variants (UMMALQURA works, Diyanet doesn't)

Lack of reliable Hijri calculations for Turkey's official calendar

Questions:

What is the intended date range for Variant.DIYANET?

Are there any known limitations or prerequisites for using this variant?

Is the Diyanet variant maintained and tested for recent/future dates?

Can you provide a working example of Variant.DIYANET usage?

Thanks in advance for your time and effort.

After checking Min&Max Values:
It seems that the problem Min&Max Values for the variants:
✓ MinHijri destekleniyor: AH-1300-01-01[islamic-umalqura]
✓ maxHijri destekleniyor: AH-1500-12-30[islamic-umalqura]
✓ minGregorian destekleniyor: 1882-11-12
✓ maxGregorian destekleniyor: 2077-11-16

✓ MinHijri destekleniyor: AH-1318-01-01[islamic-diyanet]
✓ maxHijri destekleniyor: AH-1444-05-29[islamic-diyanet]
✓ minGregorian destekleniyor: 1900-05-01
✓ maxGregorian destekleniyor: 2022-12-23

[MenoData]

Your observation is unfortunately right. The reason for this behaviour is an outdated version of the underlying diyanet data with shorter date range (until gregorian year 2022). The documentation (javadoc) of the class HijriCalendar is quite clear.

    /**
     * The name of the Turkish Diyanet-variant.
     *
     * <p>The supported range is 1318-01-01/1444-05-29 (ISO: 1900-05-01/2022-12-23). </p>
     *
     * @since   3.9/4.6
     */
    public static final String VARIANT_DIYANET = "islamic-diyanet";

The sister project Time4J, however, contains newer data. You can find it until gregorian year ~ January 2028 in:

https://github.com/MenoData/Time4J/blob/master/base/src/main/resources/data/islamic_diyanet.data

Well, I can soon update Time4A. But the main problem is updating the old build procedure based on gradle. Let me see if I can also do latter one until March / April.

[BordoBereli]

Thanks for your response. Since we have identified the root cause of the problem (the limited date range of the Diyanet variant), I hope you can have time to fix it sooner than later. I am willing to help by forking the Time4A project and contributing if that would be useful.