v0.5.0

Four calendars that only relabel the year are now accepted, and the annotation rides along. Nothing breaks.

Added

• buddhist, roc, japanese and gregory are accepted, where every non-ISO calendar was refused before. getYear('2026-01-31[u-ca=buddhist]') answers 2569, addDays returns '2026-02-01[u-ca=buddhist]', and setYear(…, 2570) returns '2027-01-31[u-ca=buddhist]'.
• The line is measured at run time, not held as a list. The month and day must equal the ISO fields, and the year offset must be constant. A calendar CLDR adds later is admitted or refused with no code change.

Changed

• A mixed calendar pair measures instead of throwing. differenceInDays('2026-03-01', '2026-01-31[u-ca=buddhist]') answers 29. Every export that takes two dates measures in one coordinate system; only a single-date field read or write honours the year label.
• temporal-polyfill/full replaces the base build, at +4.2 kB gzip. The base build cannot construct these calendars where the runtime has no native Temporal, so Node 20 and Bun would have thrown.
• day() is the normaliser and drops the annotation, so it always returns a plain ISO day.

Fixed

• Nine two-date exports measured a mixed pair in two coordinate systems and answered wrong numbers with no error. A 29-day gap read 6,513 months.
• daymath ran the bundled polyfill on every runtime, because temporal-polyfill/full never defers to native Temporal. daymath now selects the implementation itself.
• The calendar verdict cache grew without bound from caller input. 200,000 rejected ids retained 56.5 MB.

Watch out

• Never pass a calendar's own year as a bare ISO year. isLeapYear('2567-01-01') is false, while the real Buddhist 2567 is ISO 2024 and a leap year. Nothing throws. The two rules disagree in 49 of the 101 Buddhist years from 2500 to 2600.

Full detail in CHANGELOG.md and #7.