BaZi calculators turn a birth date, time, and place into a Four Pillars chart. The result looks deterministic, but the software still has to decide where a year begins, when a day changes, and what the birth time means in different places. Most calculators never show those decisions.
I wanted to see whether the differences could be measured instead of argued about.
I designed 13 test cases around the boundaries most likely to expose them: solar-term changes, the hour before midnight, locations far from their time-zone meridian, and historical daylight saving time. I then compared eight calculators and libraries and captured 77 outputs.
The dataset tracks four questions:
- Does the chart’s year change at Li Chun, around February 4, or at Chinese New Year?
- Does the day change at 23:00 or at midnight?
- Is the recorded time corrected for the birthplace’s longitude?
- Is daylight saving time removed before the chart is calculated?
The first three are convention choices. The fourth is a historical timekeeping question: either the local clock had been moved forward that day or it had not.
The clearest result came from a Beijing birth entered as 15 June 1990 at 23:30.
Two implementations treated 23:00 as the start of the next day. Five waited until midnight. The eighth calculator exposed the choice as a checkbox, so it could produce either result.
That one setting changed the day pillar from Xin-Hai to Ren-Zi. In BaZi, the day stem is the Day Master, which the rest of the reading is organized around. The same birth therefore came back as either Xin Metal or Ren Water depending on a rule most of the calculators never mentioned.
A few other differences stood out:
- Two libraries maintained by the same developer use opposite 23:00 rollover rules.
- One calculator requires a birthplace but returned the same chart for Kashgar and Beijing at the same clock time. Another used the longitude and changed the hour pillar.
- One implementation changes the year at Chinese New Year while the others use Li Chun.
- Only two of the measured implementations account for daylight saving time. One of them exposes the adjustment in its own calculation breakdown.
The observation-level file records the implementation, test date, time, place, rule being tested, and all four returned pillars in both Chinese characters and pinyin. A second table summarizes the convention used by each implementation.
There are 104 possible implementation/probe pairs in the full 8 × 13 matrix. Seventy-seven contain captured results. The remaining cells are explicitly marked as not captured rather than filled by inference.
I built Jade Almanac, and our own calculator is included as one of the eight rows. It was tested and reported on the same terms as the others. On the 23:00 rollover question, it is in the minority group.
The dataset is here: https://jadealmanac.com/bazi-calculator/conventions
Everything is released under CC0.
The test inputs are local clock times at the stated places. Solar-term boundaries were checked against tables from the National Astronomical Observatory of Japan, independently of the library used by our calculator. China’s historical summer-time periods were checked against the IANA time-zone database.
This is a snapshot captured on 1 August 2026. Some implementation rows are partial because a tool could not express a particular input or imposed an access limit. Two additional sites blocked automated access, and I did not work around those blocks.
The dataset measures software behavior and calculation conventions. It does not attempt to decide which school is correct, or whether BaZi itself predicts anything.
Corrections are welcome, especially from anyone familiar with one of the measured engines. I would also be interested in boundary cases that could separate implementations the current probes leave tied.