为什么时区会影响整张星盘
仅仅 1 小时误差，就可能让 Ascendant 移动约 15 度，整张星盘都会变。下面是我们如何处理全球时间问题。
风险很高
在占星中，Ascendant 大约每 4 分钟 改变一次。一个简单的 Daylight Savings Time (DST) 1 小时错误，可能导致：
- Ascendant Sign 错误
- House Cusps 错误
- 临界情况下 Moon Nakshatra 错误
- Dashas timelines 偏移多年
历史背景：LMT 和标准时间
19 世纪末以前，很多地方使用 Local Mean Time (LMT)。当地正午由该地点经度上的太阳位置决定。
例如，Mumbai 的 "noon" 和 Delhi 的 "noon" 并不一样。
标准化的转变
各国采用标准时区的时间不同：
- USA: Late 1883
- UK: 1880
- India: 1906 (Shifted from Madras Time to IST)
如果用现代 "Asia/Kolkata" (+05:30) 去计算 1890 年的星盘，就会出错。那时必须用根据经度计算的 LMT。
我们如何处理：AUTO 模式
当你发送 tz_str="AUTO" 时，API 会执行多步检查：
- Geographic Lookup：根据 latitude 和 longitude 找到精确 IANA timezone ID，例如
"America/New_York"。 - Historical Validation：根据出生年份检查该地区的标准化日期。
- Algorithm Selection：
- Modern Dates：使用 IANA 数据库自动处理 DST offsets。
- Historical Dates：根据精确经度切换到 LMT calculation。
BaZi 时间标准
中文命理对 Hour Pillar 精度要求很高。实践中，使用 Clock Time 还是 Solar Time 有不同派别。我们的 API 支持三个主要标准：
- Civil Time (
civil)：原始本地钟表时间。适合需要和 BaZi-Calculator 等应用保持一致的用户。 - Relative Solar Time (
true_solar)：按经度相对时区子午线修正。它保留日常时间感，同时处理大时区边缘地区。 - Absolute Solar Time (
true_solar_absolute)：纯天文日晷时间 (UTC + Longitude Offset + Equation of Time)。技术上最精确，但可能产生和本地经验不一致的柱。
[!TIP] 在中国、美国这类大国，或巴黎这类时区边界城市计算星盘时，优先使用 Relative Solar。
开发建议
- 始终使用坐标：城市名有歧义。Lat/Lng 是确定的。API 会优先用坐标判断 timezone。
- 信任
AUTO：除非你有可信来源证明某个历史 timezone offset，否则让引擎处理。