17370845950

datetime模块不处理闰秒是设计选择，因其基于理想化公历与均匀秒长模型，每天固定86400秒，且IANA时区数据库不包含闰秒数据；实际开发应放弃闰秒精度，优先应对DST切换和时区政治性变更。

datetime 模块根本不处理闰秒 —— 这不是 bug，是设计选择

为什么 strptime/strftime 和 timedelta 都无视闰秒

Python 的 datetime 模块基于“理想化公历 + 均匀秒长”模型，明确假设每天恒为 86400 秒（24 × 60 × 60），不支持闰秒插入或跳过。IANA 时区数据库（zoneinfo）本身也**不包含闰秒表**；它只记录时区偏移变更（如夏令时切换、政府调整 UTC+8 → UTC+9），而闰秒由 IERS 单独发布，需额外数据源（如 leapseconds.list 文件）。

• 调用 datetime(2016, 12, 31, 23, 59, 60) 会直接抛出 ValueError: second must be in 0..59 —— datetime 根本不承认第 60 秒存在
• time.time() 返回的 POSIX 时间戳在闰秒发生时会“重复”一秒（例如 23:59:60 → 23:59:60 再 → 00:00:00），但 datetime.utcfromtimestamp() 会将两个相同时间戳映射为同一个 datetime，造成歧义
• 所有 timedelta 运算按“每秒严格等于 1 秒”进行，不会因闰秒调整总秒数

时区转换中真正危险的边界：DST 切换与政治性偏移变更

比起不存在的闰秒，datetime 在 DST（夏令时）起止时刻和政府突然改时区的场景下更容易出错 —— 这些才是实际项目里踩坑的高发区：

• 

  “消失的一小时”：如欧洲 2026 年 3 月 29 日凌晨 01:59:59 后直接跳到 03:00:00。若用 naive datetime 构造 datetime(2026, 3, 29, 2, 30)，再用 astimezone() 转换，结果可能意外偏移
• “重复的一小时”：如美国 2026 年 11 月 1 日凌晨 02:00:00 回拨到 01:00:00，同一本地时间对应两个不同 UTC 时间点。未指定 fold 参数时，datetime 默认取第一个（较早的）时刻
• 突兀的时区变更：如 2025 年委内瑞拉将时区从 UTC-4:30 改为 UTC-4，或 2011 年 Samoa 跳过 2011-12-30 直接进入 2011-12-31 —— zoneinfo 数据库能反映这些变更，但若代码硬编码偏移量（如 timezone(timedelta(hours=8))），就完全失效

务实建议：什么该做，什么必须放弃

面对闰秒和复杂时区边界，Python 开发者应接受现实约束，聚焦可控制的环节：

• ✅ 放弃闰秒精度：金融高频交易、航天测控等真需闰秒的领域，不用 datetime，改用专门库（如 astropy.time）或 C 级别时间 API（clock_gettime(CLOCK_TAI)）
• ✅ 强制使用 aware datetime：所有涉及跨时区或持久化的操作，必须用 zoneinfo.ZoneInfo（Python 3.9+）或 pytz 绑定时区，杜绝 datetime.now() 这类 naive 调用
• ✅ DST 切换时显式处理 fold：构造本地时间时，用 datetime(2026, 11, 1, 1, 30, fold=1) 明确指定取回拨后的第二个 01:30
• ❌ 不要解析含闰秒的字符串：像 "2016-12-31T23:59:60Z" 这种格式，strptime 会失败，应提前正则替换掉 :60 或交由外部服务标准化

闰秒在绝大多数 Web/企业应用中只是理论风险，真正要绷紧神经的是 DST 规则变更通知、zoneinfo 数据库更新频率（需定期 pip install --upgrade tzdata），以及永远别相信用户输入的“本地时间”没歧义。