I started looking at BaZi, or Four Pillars of Destiny, because its output seemed oddly structured. It did not look like a paragraph of free-form symbolism. It looked like a compact record: four paired labels, each drawn from repeating sequences, with rules for translating a birth time into those labels.
As a data engineer, I’m inclined to ask what the schema is, where the boundaries sit, and what happens when the input is ambiguous. Those questions don’t prove anything about the system’s claims. They do make its calendar mechanics interesting to reverse-engineer.
A cycle built from two counters
The basic unit is a pair: one Heavenly Stem and one Earthly Branch. There are 10 stems and 12 branches. Both advance one position at a time, so the first pair returns when both counters have completed whole cycles. That takes the least common multiple of 10 and 12: 60 steps.
There’s a small combinatorics wrinkle. Ten times twelve gives 120 possible pairings if every stem could match every branch. But the traditional sequence advances both lists together, so only 60 pairings occur. Starting from Jia-Zi, the sequence proceeds Jia-Zi, Yi-Chou, Bing-Yin, and so on, until it returns to Jia-Zi.
In code, I might represent a position with an integer n:
- Stem index:
n mod 10 - Branch index:
n mod 12 - Full pair: the two indexed symbols
Advance n by one to move to the next pair. Advance it by 60 and the pair is back where it started. That’s the core periodic algorithm: two clocks with different periods, sharing one step counter. (aa.usno.navy.mil)
The 60-step sequence can label years, months, days, and hours, but those are not one giant clock ticking at the same speed. Each unit has its own rule for finding the current position in the cycle. The shared encoding makes the labels comparable; the calendar conventions decide where one unit ends and the next begins.
Turning a timestamp into four pillars
A chart has four pillars: year, month, day, and hour. Each pillar is one stem-branch pair. A simplified software pipeline looks something like this:
- Parse the birth timestamp, location, and time-zone context.
- Convert the timestamp to the calendar’s working local time.
- Determine which year and solar-term month contain it.
- Find the sexagenary day index.
- Divide the day into two-hour branch intervals, then derive the hour stem from the day stem.
The year pillar is not always switched at the same boundary across every convention. Many BaZi methods use the solar term Li Chun as the year boundary rather than Lunar New Year. Month pillars also follow solar terms: the year is divided into 12 solar months, with month changes anchored to particular terms. So a person born in early February may land on different year labels under different year-boundary conventions.
The day pillar is a position in its own 60-day sequence. The hour branch divides the day into 12 two-hour periods; for example, Zi is commonly associated with roughly 11 p.m. to 1 a.m. The hour stem is not an independent counter that can be looked up from clock time alone: its assignment is linked to the day stem.
This is why two implementations can accept the same date and still disagree. They may be using different boundaries, different day-rollover conventions, or different assumptions about what “local time” means. The symbolic lookup can be perfectly consistent while the input normalization differs.
Civil time is not solar time
A timestamp such as 01:30 is a statement about a clock, not directly about the Sun’s position. Civil clocks follow time-zone rules. Apparent solar time follows the Sun’s local position, which varies with longitude and with the equation of time.
The IANA Time Zone Database is useful here because it records time-zone offsets and daylight-saving transitions for named regions. But historical coverage and confidence vary, especially for dates before 1970. A location name alone is not enough; a robust input needs a date and a specific zone, and an ambiguous local time may also need its UTC offset or an explicit “first or second occurrence” marker. (iana.org)
Consider New York on November 7, 2021. At the end of daylight saving time, clocks moved from 2:00 a.m. daylight time back to 1:00 a.m. standard time. That means 01:30 occurred twice: once at UTC−4 and again at UTC−5. A timestamp containing only the city and wall-clock reading cannot distinguish those two instants. The IANA zone rules can resolve the transition once the input identifies which occurrence it means. (timeanddate.com)
If a method uses true solar time, there is another adjustment. First resolve the civil time-zone offset, including daylight saving time. Then account for longitude relative to the time zone’s standard meridian, and for the equation of time. As a rough rule, each degree of longitude corresponds to about four minutes of solar-time difference. New York is near 74° west, while Eastern Standard Time is based on a 75° west meridian, so the longitude correction is about four minutes ahead of standard clock time. The equation-of-time adjustment varies by date and can reach around 16 minutes. (aa.usno.navy.mil)
Those minutes matter most near a boundary. If the corrected time falls close to a two-hour branch change, different normalization choices could produce a different hour branch. Near a day boundary, a convention for when the sexagenary day turns over could affect the day pillar too. This is less a mystical mystery than a familiar data-quality issue: the model has edge cases, and the pipeline needs to state its assumptions.
The ten-year phase as a state machine
BaZi also describes longer luck cycles, often called decade pillars. In many methods, a sequence of these ten-year phases is derived from the month pillar. The direction of travel and the starting age depend on conventions that can involve the birth year and the distance to a nearby solar term. Each phase advances through the stem-branch sequence, with a new phase roughly every ten years.
That invites a state-machine analogy. The birth chart is the initial state; the decade pillar is a phase that changes at a calculated boundary; the current year and other calendar cycles provide additional inputs. A reader can describe the state at a given date by identifying which phase is active and which cycle labels apply.
The analogy has limits. A state machine tells us how labels change under stated rules. It does not establish that those labels cause or reliably describe events. Also, a ten-year phase is not simply “one sixth of a 60-year loop” in every practical calculation: its start and direction depend on conventions, and other calendar boundaries run alongside it.
Still, the algorithmic structure is elegant. A small number of cyclic counters, plus carefully defined transition rules, produce a compact time-based representation. The trickiest part is not the modulo arithmetic. It is agreeing on the exact instant and the calendar rules before the arithmetic begins.
Boundaries
I treat BaZi as a cultural-computational system for insight and reflection, not a tool for forecasting outcomes. The cycle math can be described and tested; that does not validate claims that chart labels determine a person’s character or life events. I make no outcome claims here. At most, the system can serve as entertainment or a prompt for decision-support conversations, with real-world decisions grounded in evidence relevant to the decision itself.
What I'm still unsure about
- Which time-normalization convention is most faithful to historical BaZi practice: civil clock time, local mean solar time, or apparent solar time?
- How much do different schools’ boundary rules change charts in practice, especially for births near midnight or a solar-term transition?
- Can a software implementation clearly expose uncertainty in old time-zone records without making the chart interface unreadable?
Top comments (0)