不会。Python标准库的datetime、time和calendar均无视闰秒，因POSIX时间戳将每分钟视为60秒，23:59:60被“压平”；需闰秒感知时应使用astropy.time等专用库。
Python 里 datetime 会自动处理闰秒吗？
不会。标准库的 datetime、time 和 calendar 全部无视闰秒——它们把时间当成连续的线性刻度，而闰秒是“断点”。比如 2016-12-31 23:59:60 这个合法的国际时间，在 datetime.strptime('2016-12-31 23:59:60', '%Y-%m-%d %H:%M:%S') 里直接抛 ValueError: second must be in 0..59。
原因很简单：POSIX 时间戳（即 time.time() 返回值）本身就不表示闰秒。它把每分钟都当作 60 秒，把 23:59:60 “压平”进下一秒的时间戳里。Python 完全跟随 POSIX 语义。
所以别指望靠改格式化字符串或换时区就能“支持”闰秒——底层模型不支持，上层再绕也没用。
需要闰秒感知时，该用哪个库？
目前唯一被广泛验证可用的是 leapseconds（配合 astropy 或手写转换逻辑），但更稳妥的选择是 pytz + 外部闰秒表，或者直接用 astropy.time。
立即学习“Python免费学习笔记（深入）”；
astropy.time 是少数真正区分 TAI（原子时）、UTC（协调世界时）和 UT1 的 Python 工具：
from astropy.time import Time
t = Time('2016-12-31 23:59:60', scale='utc', format='iso')
print(t.tai.iso) # 输出：2017-01-01 00:00:36.000注意：scale='utc' 才能解析闰秒字符串；若用 scale='tai' 或默认值，23:59:60 会被拒。
常见踩坑点：
-
astropy默认不自带最新闰秒表，首次运行可能报ERFAWarning: DUT1 not available，需手动执行astropy.utils.iers.download_iers_a() - 闰秒数据有延迟：IANA 每次公告后，
astropy通常 1–2 周才同步，生产环境建议定期update_iers - 不用
astropy时，硬上pytz也没用——它只管时区偏移，不管秒级跳变
自己解析闰秒文件靠谱吗？
可以，但仅推荐用于离线校验或嵌入式场景。IANA 官方闰秒文件 leap-seconds.list 是纯文本，格式稳定：
# @(#)leap-seconds.list 8.13 # Leap seconds from NIST # # This file is in the public domain. # # Format: # LEAP UTC Date TAI-UTC # 2272060800 1972-01-01 10 # 2287785600 1972-07-01 11 # ...
关键点：
- 第一列是 TAI 时间戳（秒数，起点为 1900-01-01），不是 UNIX 时间戳，要减去
2208988800才能对齐time.time() - 每一行代表“从该 UTC 时刻起，TAI-UTC 偏移增加 X 秒”，不是“该秒存在”
- 23:59:60 出现在 UTC 时间线上，但对应的时间戳和前一秒相同（POSIX 规则），不能靠
time.gmtime()反推
所以自己 parse 只能辅助判断“某 UTC 时间是否在闰秒窗口内”，不能用来构造可计算的 datetime 对象。
生产系统要不要真处理闰秒？
绝大多数不需要。金融、日志、API 时间戳、数据库写入——全部基于 POSIX 时间戳，天然跳过闰秒。强行加入闰秒逻辑反而引入非幂等、难测试、跨平台不一致的问题。
真正要处理的场景极少：
- 射电天文、卫星轨道推算等依赖 TAI/UT1 精密对时
- 与外部高精度授时设备（如 GPS 接收器）做时间比对
- 归档级科学数据标注，要求 UTC 秒字段严格符合 IERS 公告
最容易被忽略的一点：即使用了 astropy，只要最终落到 time.time()、datetime.timestamp() 或数据库 TIMESTAMP 字段，闰秒信息就丢失了——这些载体本身不存“第61秒”的概念。
