Public Research Fixture · v0.1
八字排盘计算器规则对照
BaZi Calculator Benchmark: Time Zones, Solar Terms & True Solar Time
为什么同一个出生时间，在不同排盘工具里可能出现不同结果？问题通常不在“八字公式”四个字本身，而在节气交界、历史时区、夏令时、真太阳时和子时换日等输入政策。本页先发布一组不含真实个人资料的可复现测试夹具，帮助开发者和读者把这些政策逐项拆开核对。
Reference fixtures
8
合成边界案例
Core policies
4
节气、时区、太阳时、换日
Linked sources
6
权威资料与开源实现
先看这 4 个容易被忽略的边界
历法边界
节气是太阳位置的时间点，不能只看搜索结果里显示的公历日期。
时间基准
出生地的历史时区和夏令时决定民用时间对应的唯一瞬间。
太阳时政策
经度修正、均时差和是否跨日，必须单独记录而不是静默覆盖输入。
换日规则
23:00 换日与 00:00 换日是不同政策，结果应带着规则一起展示。
Reference Fixtures
这些案例是测试输入和预期检查点，不是对某个商业计算器的排名。下一版会在保留原始输入的前提下，追加不同开源引擎和公开工具的实际输出、运行日期与版本。
| Scenario | Synthetic input | Declared policy | What to verify |
|---|---|---|---|
| 节气交界solar-term-crossing | 2026-02-04 立春交接点前后各 60 分钟 | Asia/Hong_Kong；以精确交接时刻判断，不以整天判断 | 同一民用日期的交接前后，月柱边界应明确可复核 |
| 节气时间基准term-timezone | 2026-02-18 23:52 HKT（雨水交接） | 将 HKT、UTC 与出生地时区转换后再比较 | 同一个瞬间不应因展示时区不同而被当成不同交接 |
| 历史夏令时historical-dst | 2000-01-15 12:00 Australia/Melbourne | 使用该地点和日期的 IANA 历史时区规则 | 夏令时偏移应先还原为唯一时间瞬间，再进入后续计算 |
| 经度与真太阳时longitude-correction | 2000-01-01 00:30；乌鲁木齐，87.6168°E | 保留民用时间，同时单独记录经度修正和均时差 | 衍生太阳时可能落到前一日期，不能覆盖原始出生记录 |
| 半小时区时fractional-timezone | 2000-01-01 12:00；Kolkata，77.5946°E | 保留 Asia/Kolkata 的 UTC+05:30，不四舍五入成整小时 | 时区偏移和经度修正都应进入可审计的计算记录 |
| 晚子时换日late-zi-boundary | 2000-01-01 23:30 Asia/Shanghai | 分别运行 23:00 换日和 00:00 换日两种明确规则 | 规则不同可以产生不同日柱，但每种结果都必须标注规则 |
| 午夜边界midnight-boundary | 2000-01-02 00:30 Asia/Shanghai | 与前一条晚子时案例成对比较 | 日柱和依赖日干的时干不能出现部分更新的混合结果 |
| 南半球出生地southern-hemisphere | 2026-02-04 12:00 Australia/Sydney | 历法边界、时区、经度与季节性解释分开记录 | 不能因为出生在南半球就隐式反转节气或四柱算法 |
How to use this dataset
- 先把民用出生时间、地点和 IANA 时区保存为原始输入，不要直接覆盖。
- 分别记录节气、真太阳时和换日规则，确认每一步使用的时间基准。
- 在边界前后各运行一次，保存四柱输出和引擎版本。
- 如果结果不同，先定位是哪一层政策不同，再讨论流派解释。
Dataset license: CC BY 4.0。可以复用和扩展，请保留天机玄鉴页面链接与来源说明。
Sources and implementations
从规则核对，到实际排盘
如果你想把测试输入带入完整的四柱排盘与 AI 解读流程，可以继续查看 AstrologyBazi 的免费 BaZi Calculator。
打开 AstrologyBazi →