v0.4.0

day() — the one way a moment enters daymath — plus a cross-runtime test lane that proves the rest of the API answers identically everywhere.

Breaking

• Node 18 is dropped. engines is now >=20.19.0 <21 || >=22.12.0, which states the real constraint: require('daymath') needs Node's require(esm), added in 20.19 and 22.12. Node 18, 21 and 22.0–22.11 will warn on install.
• Error messages no longer quote Temporal's own wording. addDays could not produce a valid date (Out-of-bounds date) is now addDays could not produce a valid date. The original error is on cause. Match on the class, not the text.

Added

• day(moment?, tz?) returns the calendar day of a moment, in a zone. It takes a Date, epoch milliseconds, an ISO day, a Temporal.PlainDate, or an ISO timestamp. Both defaults are stated: the moment is now, the zone is UTC. It is the only export that reads a clock, and the only door a Date enters by.
• npm run test:runtimes, a recorded baseline over every export, run on Node, Deno (native Temporal) and Bun.
• Lint, format and type gates: oxlint, oxfmt, and tsc --checkJs over the JSDoc.

Fixed

• A Temporal.PlainDate from another implementation is accepted. isValid used to answer false for a valid date from native Temporal, or from a second copy of temporal-polyfill in the same dependency tree.
• A non-ISO calendar is refused rather than reinterpreted, and the error names it. [u-ca=iso8601] is accepted and dropped, because Temporal writes it itself.
• The six interval-reading exports name the interval, rather than blaming a property the caller never passed.

Full detail in CHANGELOG.md and #5.