Bug: uaqToHijri read local date components (getFullYear/getMonth/getDate)
and passed them to Date.UTC(), producing a UTC midnight that does not match
the input's intended Gregorian day on hosts west of UTC. Concretely, a Date
returned by toGregorian() (UTC midnight) would map to the *previous* Hijri
day on UTC-5 or UTC-13 hosts, breaking the toHijri(toGregorian(hy,hm,hd))
round-trip.
Fix: switch line 44 to read UTC components (getUTCFullYear/getUTCMonth/
getUTCDate), matching how the FCNA engine already worked. Both engines now
share the same UTC-day contract: toHijri reads the UTC calendar day of the
input, and toGregorian returns a UTC-midnight Date. Round-trips are exact;
results are host-timezone-independent.
Behavior change: on non-UTC hosts, toHijri results may shift to the UTC
calendar day rather than the local calendar day. Users passing local
wall-clock dates should use new Date(Date.UTC(y, m-1, d)).
Also:
- Fix misleading comment in uaqToHijri (previously claimed local components
were "timezone-safe")
- Add UTC-day contract to toHijri JSDoc in src/index.ts
- Fix wrong constraint comment in hijri-core.test.ts header
- Add "day boundaries (UTC contract)" describe block to vitest suite
- Convert LOCAL Date constructors in test.mjs and test-cjs.cjs to
Date.UTC() form; add UAQ round-trip assertion to test.mjs
- Add "Day boundaries and time zones" section to README.md
- Add [Unreleased] Fixed entry to CHANGELOG.md
Zero-dependency Hijri calendar engine with pluggable calendar registry.
Built-in Umm al-Qura (UAQ) and FCNA/ISNA calendar engines. Supports N
additional calendars via registerCalendar(). Pure Date.UTC arithmetic,
binary search on 184-entry UAQ table, Meeus Ch.49 new moon formula for
FCNA. 39 ESM + 20 CJS tests passing. Dual CJS/ESM build with full TypeScript
declarations.
