Solar Terms Are Moments, Not Days

A BaZi chart has four pillars, and the month pillar is the heaviest thing in it. The strength verdict weights the month branch above every other factor, because the month is the season and the season is what a day master either has behind it or doesn't.

That pillar does not turn on the first of the calendar month. It turns at a solar term — the instant the sun's apparent longitude reaches a particular value.

An instant. Not a date.

Two errors follow from missing that, and they are different sizes. I shipped the second one.

Error one: the year doesn't turn at Lunar New Year

This one is common, straightforward, and not a school position.

The year pillar changes at 立春, the first solar term, when the sun reaches 315° of longitude. It does not change at the lunar new year, which is a different event on a different calendar.

They are usually within a few weeks of each other, which is why the mistake survives. Here is how far apart they actually run:

Note the third column. They swap. In 2023 and 2025 the lunar new year came first; in 2024 and 2026 立春 did.

So a calculator using the lunar new year isn't consistently early or consistently late. It's wrong in one direction some years and the other direction other years, for a window of days to weeks — and everyone born in that window gets a year pillar one full term off. Not adjacent. A different pair of characters entirely.

Error two: a term is a moment

This is the subtler one, and it is where I have something to declare.

立春 2025 happened at 23:07 on 3 February, Korean time. 立春 2021 at 23:56 on 3 February. Both a day earlier than the February 4 that almost every reference gives.

A calculator working from a table of days has to pick one date per term and apply it to every year. That table is right in some years and wrong in others, and the births it gets wrong are the ones on the boundary — which are exactly the births where the month pillar is in question.

What I found in my own engine

This site used a table of days until I replaced it.

The old code carried twelve hardcoded dates — 立春 Feb 4, 驚蟄 Mar 6, 清明 Apr 5, and so on — and compared each birth's calendar date against them. The comment above it said representative boundary day, which was honest, and I did not think hard enough about what "representative" was costing.

When I replaced it with a computed instant and compared the two across 1988 to 2026, eleven of the twelve terms were wrong in at least one year. Only 大雪 was never wrong.

And the errors were not scattered. They cycle with the leap year:

terms wrong per year, by position in the leap cycle, 1988–2026

  leap year   6 6 6 6 6 6 6 6 6 7
  leap + 1    4 4 5 6 6 6 7 7 8 8
  leap + 2    2 2 2 1 1 3 3 3 4 5
  leap + 3    2 2 2 2 2 2 1 1 2

The table had been tuned — by whoever first wrote those dates down — to the phase where the terms fall latest. In leap + 3 years it has almost no late misses. Then the leap day pulls every term back by about eighteen hours, the error peaks, and it decays over the next three years — each common year pushing the terms roughly six hours later again.

In nine of the ten leap years in that window, six terms were a full day late at once.

There is also a drift. The count grows with time — 2021 and 2025 reach eight — because the table is a snapshot of one era applied to all of them. Extended forward, by the 2060s a leap year would have been wrong for eleven of the twelve.

None of this threw an error. A birth on a boundary day got the wrong month pillar and a chart that looked exactly like a correct one. The chart is eight characters either way. That is the failure mode: plausible output, no error, nothing to notice.

What replaced it, and how accurate it actually is

The term is now computed as the instant the sun's apparent geocentric longitude reaches a multiple of 30° from 315°, solved by Newton iteration on the standard algorithm.

Two numbers, and they are different numbers:

Resolution: milliseconds. The solver converges to well under a second of time, and never approaches its iteration budget.

Accuracy: about ten minutes. That is the error floor of the solar position model, not of the solver. A more precise model would tighten it; this one is stated as good to roughly 0.01° of longitude, which is about a quarter hour of time.

Those are independent, and conflating them is how a system claims more than it has.

Checked against two published almanacs. Against the Hong Kong Observatory's 2024 almanac, six terms:

雨水   published 12:13   computed 12:10   −2.3 min
穀雨   published 22:00   computed 21:56   −3.7 min
夏至   published 04:51   computed 04:48   −2.7 min
處暑   published 22:55   computed 22:49   −5.2 min
霜降   published 06:15   computed 06:06   −9.0 min
冬至   published 17:21   computed 17:13   −7.8 min

Every calendar date agrees. Every clock time runs early, by two to nine minutes. The bias is one-directional in all six, which is the signature of the model rather than of noise — a more precise model would move them all the same way.

Against The Astronomical Almanac, six sectional terms, all dates correct — including 寒露 2000, which lands 28 minutes before rolling over to the next day.

The honest residual

Ten minutes of accuracy and a calendar-day assignment means one thing: a term landing within ten minutes of midnight is genuinely uncertain.

Over 1900 to 2099 that is 38 terms out of 2,400 — about 1.6%. The tightest:

驚蟄 1919   00:00 KST
立秋 1919   00:00 KST
立冬 1998   00:01 KST
寒露 2077   00:01 KST

立冬 1998 at one minute past midnight is inside the engine's own error bar. I cannot tell you which side of the boundary it falls on, and neither can the engine, and saying so is more useful than picking one.

That residual is roughly a hundred times tighter than the day-scale error it replaced. It is not zero.

Why this matters more than the hour

An hour pillar is one of four, and getting it wrong costs a quarter of the chart.

The month pillar is different. 得令 — whether the month branch supports the day master — carries more weight in the strength verdict than any other factor. Move the month pillar and the verdict can invert: a chart that read strong reads weak, and the prescription reverses with it.

So a boundary-day birth isn't a chart with one character in doubt. It's a chart where the central judgement is in doubt, and everything downstream of that judgement with it.

Which is why a calculator should tell you when you're on one. If it doesn't, it either isn't checking or isn't saying.