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默认取第一个（较早的）时刻 -
突兀的时区变更：如 2024 年委内瑞拉将时区从 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），以及永远别相信用户输入的“本地时间”没歧义。
