Benchmark
Thirty BaZi charts you can test against
Two calculators disagreeing on a chart is not an argument — it is a bug in one of them. This is a fixed set of inputs and answers, so the disagreement becomes measurable.
The four pillars are arithmetic, not interpretation. That is the only thing this benchmark asserts. Element weights are included but compared with a tolerance, because the coefficients are a modelling choice and differ between schools.
Download the set
The archive contains the data, the reference engine, and a harness that re-runs every case. No dependencies, no account, no build step.
Then: unzip bazi-benchmark.zip && cd bazi-benchmark && node harness/run.mjs
· raw data: reference-charts.json
· code MIT, data CC BY 4.0
Current result
30 reference charts, all four pillars agree. Engine against locked expectations: 30/30. Engine against an independent implementation that shares no code: 30/30. Element weights within 0.6 points: 30/30.
Run on 2026-10-20. Regenerated from the same suite the live site runs at /tests.
The conventions this set assumes
Most disagreements between BaZi calculators are disagreements about conventions, not arithmetic errors. Stating them is what makes a mismatch diagnosable.
| Question | This set uses |
|---|---|
| When does the day pillar advance? | 23:00 local true solar time (子时换日). Not midnight. |
| Year and month read from local or absolute time? | Absolute instant (UTC) — solar terms happen at one moment worldwide. |
| Correct clock time to true solar time? | Yes — longitude offset from the standard meridian, plus equation of time. |
| Which terms start a month? | The twelve 節 (立春, 惊蛰, 清明 …), not the 中氣. |
| Leap lunar month | Creates no month pillar. Months follow solar terms. |
| Element weights | stems 1.0, branches 0.8, hidden stems 0.3 each, normalised to 100%. |
How far the clock is from the sun
Every case below stores the shift between the clock on the wall and the sun at the birthplace: longitude offset from the standard meridian, plus the equation of time. Across these 30 charts it is not a rounding detail — the median is 16 minutes, and the largest, Madrid keeping CET at 3.7°W, is 85.
A shift of s minutes moves a uniformly-timed birth across a two-hour pillar boundary with probability s/120, and across the 23:00 day boundary with probability s/1440. At the mean shift of 20 minutes that is 17% of charts landing in the wrong hour pillar and 1.4% in the wrong day pillar — for any calculator that skips the correction entirely.
The 30 cases
| # | Local time | Place | Expected pillars | True solar | Governing term |
|---|---|---|---|---|---|
| 1 | 1990-05-20 14:30 | New York City | 庚午 辛巳 乙酉 癸未 | 1990-05-20 13:37 | Lixia |
| 2 | 1990-01-20 14:30 | New York City | 己巳 丁丑 乙酉 癸未 | 1990-01-20 14:23 | Xiaohan |
| 3 | 2023-07-01 23:30 | New York City | 癸卯 戊午 庚申 丁亥 | 2023-07-01 22:30 | Mangzhong |
| 4 | 2023-01-01 06:15 | New York City | 壬寅 壬子 己未 丁卯 | 2023-01-01 06:16 | Daxue |
| 5 | 2023-11-05 01:30 | New York City | 癸卯 壬戌 丁卯 庚子 | 2023-11-05 00:50 | Hanlu |
| 6 | 2000-01-01 12:00 | London | 己卯 丙子 戊午 戊午 | 2000-01-01 11:56 | Daxue |
| 7 | 1975-08-15 04:45 | London | 乙卯 甲申 癸巳 甲寅 | 1975-08-15 03:39 | Liqiu |
| 8 | 2010-06-21 18:00 | Paris | 庚寅 壬午 壬寅 戊申 | 2010-06-21 16:08 | Mangzhong |
| 9 | 2010-12-21 18:00 | Paris | 庚寅 戊子 乙巳 乙酉 | 2010-12-21 17:11 | Daxue |
| 10 | 1995-09-09 09:09 | Berlin | 乙亥 乙酉 癸卯 丙辰 | 1995-09-09 08:05 | Bailu |
| 11 | 2022-03-15 07:20 | Madrid | 壬寅 癸卯 丁卯 癸卯 | 2022-03-15 05:55 | Jingzhe |
| 12 | 1988-04-02 22:10 | Sydney | 戊辰 乙卯 丁亥 辛亥 | 1988-04-02 22:11 | Jingzhe |
| 13 | 2001-12-25 11:00 | Sydney | 辛巳 庚子 壬戌 乙巳 | 2001-12-25 10:05 | Daxue |
| 14 | 1969-07-20 20:17 | Melbourne | 己酉 辛未 丙申 戊戌 | 1969-07-20 19:50 | Xiaoshu |
| 15 | 1993-10-30 16:00 | Auckland | 癸酉 壬戌 甲申 辛未 | 1993-10-30 14:55 | Hanlu |
| 16 | 2015-04-01 05:30 | Auckland | 乙未 己卯 丁未 壬寅 | 2015-04-01 04:04 | Jingzhe |
| 17 | 1999-07-04 13:45 | Toronto | 己卯 庚午 丁巳 丙午 | 1999-07-04 12:23 | Mangzhong |
| 18 | 1999-02-04 13:45 | Toronto | 己卯 丙寅 丁亥 丁未 | 1999-02-04 13:13 | Lichun |
| 19 | 2008-08-08 20:00 | Beijing | 戊子 庚申 庚辰 丙戌 | 2008-08-08 19:39 | Liqiu |
| 20 | 2020-02-29 10:00 | Shanghai | 庚子 戊寅 壬寅 乙巳 | 2020-02-29 09:52 | Lichun |
| 21 | 1997-05-05 03:00 | Tokyo | 丁丑 甲辰 丁未 壬寅 | 1997-05-05 03:22 | Qingming |
| 22 | 2012-11-11 11:11 | Seoul | 壬辰 辛亥 丙子 癸巳 | 2012-11-11 10:54 | Lidong |
| 23 | 1980-03-21 21:00 | Singapore | 庚申 己卯 癸巳 壬戌 | 1980-03-21 20:17 | Jingzhe |
| 24 | 2018-06-15 14:00 | Dubai | 戊戌 戊午 戊寅 己未 | 2018-06-15 13:41 | Mangzhong |
| 25 | 1991-12-31 23:45 | Mumbai | 辛未 庚子 丙子 戊子 | 1991-12-31 23:03 | Daxue |
| 26 | 2005-01-15 08:00 | Johannesburg | 甲申 丁丑 己亥 戊辰 | 2005-01-15 07:43 | Xiaohan |
| 27 | 2016-08-05 19:30 | Sao Paulo | 丙申 乙未 己未 甲戌 | 2016-08-05 19:17 | Xiaoshu |
| 28 | 1978-02-28 12:00 | Mexico City | 戊午 甲寅 辛酉 甲午 | 1978-02-28 11:10 | Lichun |
| 29 | 1949-10-01 15:00 | Beijing | 己丑 癸酉 甲子 辛未 | 1949-10-01 14:56 | Bailu |
| 30 | 2026-01-01 00:05 | Los Angeles | 乙巳 戊子 乙亥 丙子 | 2026-01-01 00:09 | Daxue |
Latitude, longitude, timezone, DST offset and the full solar-time correction for each case are in the JSON, not in this table.
What this benchmark does not cover
Every one of the 30 cases sits clear of a solar-term boundary — which is exactly why two implementations can be compared at all. The independent implementation solves solar terms with the Meeus low-precision series, documented in its own source as good to roughly ±15 minutes.
That was measured, not assumed. Sweeping minute by minute across 立春 2026-02-04 04:02:08 (UTC+8), the two agree from 10 minutes out and start to disagree inside roughly 6 minutes before the term. So this page claims one thing and not the other:
✅ 30 charts, all four pillars agree with locked values and with an independent implementation. ❌ Anything about the last few minutes before a solar term. Those are shown here instead of being folded into a pass rate. Boundary cases are the most useful thing you could contribute.
Score your own calculator
Write the four pillars your implementation produces for each case id, then:
node harness/compare.mjs my-results.jsonOnly pillars are compared. If your calculator is right and this set is wrong, that is worth an email — a benchmark that cannot be contradicted is not a benchmark.
Citing this
WuWay, "BaZi reference charts", https://getwuway.com/benchmark (2026-10-20)Data CC BY 4.0 — reuse with attribution. Code MIT. The same charts with the full derivation are at /reference-charts.
The set also lives on GitHub, so you can run it without trusting this site:
github.com/getwuway/bazi-benchmark
· CITATION.cff included for reference managers.
The live verification run · Boundary cases · Calculate your own