mirror of
https://github.com/acamarata/hijri-core.git
synced 2026-06-30 18:54:27 +00:00
34193780f3
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
9 lines
177 B
TypeScript
9 lines
177 B
TypeScript
import { defineConfig } from "vitest/config";
|
|
|
|
export default defineConfig({
|
|
test: {
|
|
globals: true,
|
|
environment: "node",
|
|
include: ["hijri-core.test.ts"],
|
|
},
|
|
});
|