v0.1.3 — solar terms, computed
If you installed 0.1.0, please upgrade. Charts for births on a solar-term day were wrong in most years.
(0.1.3 supersedes the v0.1.2 tag, which was cut before CI reported a Node 20 failure and never reached npm.)
What was wrong
The calendar dataset's getSolarTermsByYear(year) returns the same table for every year — 입춘 pinned at Feb 4, 05:02 KST for 2020 through 2030. The real instants:
| year | dataset | computed (KST) |
|---|---|---|
| 2024 | Feb 4, 05:02 | Feb 4, 17:26 |
| 2025 | Feb 4, 05:02 | Feb 3, 23:10 |
| 2026 | Feb 4, 05:02 | Feb 4, 05:01 |
| 2027 | Feb 4, 05:02 | Feb 4, 10:46 |
Twelve hours in one direction, a different day in another. 0.1.0 trusted it, so a term-day birth in any year 2020–2030 except 2026 could get the wrong year or month pillar.
What changed
- Solar-term instants are now computed from solar ecliptic longitude (astronomy-engine), 1900–2050 — within one minute of the KASI-derived values.
- Year and month pillars are derived from those instants rather than the dataset's day-level month table, which flips a day late at many terms (경칩 2024 = Mar 5 11:22 KST, table flips Mar 6).
- December 31 year-stem corruption in the dataset (12 years in range) is bypassed.
- Luck-pillar starting age measured against the instants;
daysToTermreturned so you can audit it. - Regression guard for the bug class: a test asserting that different years produce different term instants. The original failure was invisible because the engine and the fixtures read the same table.
astronomy-engineimported through namespace interop — the named import threw on Node 20, a runtime this package declares support for.
Off the boundaries, old and new agree on every day from 1905 to 2049 — that sweep is a test. 28 tests, green on Node 20 and 22.
Full detail: CHANGELOG.md · what comes next: ROADMAP.md