Case 02 of 26
Solar-term boundaries
After Lichun: the Bazi year changes
The paired case moves beyond Lichun and changes both year and month pillars.
Boundary question
What changes after the Lichun boundary has passed?
The chart moves to the Bing-Wu (丙午) year and Geng-Yin (庚寅) month, showing that the boundary is solar-term based.
Synthetic input
Recorded facts
- Date
- 2026-02-05
- Recorded time
- 12:00
- Location
- 120°E reference meridian
- Time zone
- Asia/Shanghai
- Longitude
- 120.0000°
- Gender input
- Male
Pinned expected facts
Verified output
Year
丙午
Month
庚寅
Day
庚戌
Hour
壬午
- Day Master
- 庚
- True solar time
- 2026-02-05 11:46
- Total correction
- -13.74 minutes
- Historical offset
- UTC+08:00 · DST 0 min
- Luck direction
- 顺排
- Reference Jie
- 惊蛰 · 2026-03-05 21:59:00
- Luck start
- 2035-07-26 13:16:15
Reading the boundary
What this case means for your own chart
This is the other half of a controlled pair. The previous case sits before Lichun; this one sits two days after it, with everything else held constant. Reading the two side by side is the fastest way to see that the year boundary is a solar-term event rather than a calendar-page event.
What changes is not only the Year Pillar. The Month Pillar moves as well, from Ji-Chou to Geng-Yin, because Lichun is also the start of the first solar month. One boundary, two pillars. That is why a person born a few days either side of Lichun can end up with a chart that looks structurally different from a sibling born in the same week.
The practical consequence is that a birth date alone cannot settle your chart if you are near this boundary. You need the clock time, and you need it checked against the solar-term timestamp rather than rounded to the nearest day. This page shows exactly what the engine does with a clean post-boundary input so you have a reference point.
It is also worth noting what a paired case like this cannot establish. These two records are two days apart, so they show which side of the boundary each input occupies but not the boundary's exact minute. They do not validate the engine against an independent ephemeris. The suite as a whole is a consistency check on stated rules, not an external proof that those rules match every other published source.
Check your own record
- Look up the Lichun timestamp for your birth year and compare it to your recorded birth time on the same clock.
- If your time is after Lichun, expect both the Year and Month Pillars to have moved. If it is before, expect both to still belong to the previous solar year.
- Check that any calculator you compare against is using a solar-term boundary at all, before assuming one of them is wrong.
Which convention is in play
- Calculation fact
- A 5 February 2026 record returns the Bing-Wu year and Geng-Yin month, two days after the paired pre-Lichun case.
- Convention
- Treating Lichun as the year boundary is the convention this calculator states. Other published systems key the year to Lunar New Year instead.
- Our explanation
- Pairing the two cases is our presentation choice. It makes the boundary visible in a way a single case cannot.
Conventions and limits
What this case does — and does not — prove
It verifies
Deterministic reproduction of this input under the named engine version and conventions. A pinned-field mismatch stops the production build.
It does not claim
Universal agreement across Bazi schools, interpretation of a real person, or certainty where the historical record is incomplete.
tyme4ts 1.5.2 · sect 2 day boundary · BaziCalculator.ai NOAA/IANA true-solar adapter
calculation-benchmarks-v1 · reviewed 2026-09-05