C++标准库无法直接判断闰秒，因其不存储闰秒信息；必须依赖IERS发布的leap-seconds.list文件，解析后比对UTC时间戳与闰秒生效时刻。
闰秒不是日期本身的属性，C++标准库无法直接判断
“闰秒”不是某个日期（比如 2016-12-31）自带的元数据，它属于全球协调世界时（UTC）的历法修订记录。C++ 标准库（包括 <chrono>、<ctime>）所有类型（如 std::time_point、std::tm）都不存储或暴露闰秒信息——它们默认假设平滑的TAI–UTC偏移，且不提供闰秒表查询能力。
所以，你不能对一个 std::chrono::system_clock::time_point 调用某个函数就返回 “是否含闰秒”。闰秒只发生在特定 UTC 时刻（通常是 6 月 30 日或 12 月 31 日 23:59:60），而这个“60秒”本身在 C++ 中甚至无法被 std::tm 的 tm_sec 字段合法表示（其取值范围是 0–60，但 60 仅用于表示闰秒，且多数 libc 实现会截断或忽略）。
要判断某 UTC 时间点是否处于闰秒事件中，必须查外部闰秒表
国际地球自转服务（IERS）定期发布闰秒公告，最权威的数据源是 IERS 的 leap-seconds.list 文件（文本格式，含 TAI–UTC 偏移变更时间戳）。你需要：
- 下载并定期更新
leap-seconds.list（例如从 https://www.php.cn/link/ddc6dcb682f8fa80f20e986207d14e79） - 解析该文件，提取每个闰秒生效的 POSIX 时间戳（即 TAI − 10 秒对应的 Unix 时间）
- 将你的目标 UTC 时间（需精确到秒，且确认是 UTC，非本地时区）转换为
std::time_t（即 Unix 时间戳） - 检查该时间戳是否等于某个闰秒生效时刻（即该秒的末尾发生了闰秒插入）
注意：闰秒发生于 UTC 的 23:59:60，对应 Unix 时间戳是“该分钟起始时间 + 60”，但实际在系统中通常表现为两个连续的 23:59:59（双秒）或跳变；leap-seconds.list 中记录的是“新偏移量开始生效”的 TAI 时间，需换算为 UTC 对应的 Unix 时间（减去当前 TAI−UTC 偏移）。
立即学习“C++免费学习笔记（深入）”；
实际代码中容易踩的坑
常见错误包括：
- 误用
std::mktime()或std::gmtime()处理tm_sec == 60：绝大多数 C 库实现将tm_sec = 60视为非法，直接返回 -1 或静默修正为 0 - 把本地时间当 UTC 传入判断：闰秒只定义在 UTC，时区转换会破坏时间点语义
- 忽略闰秒表过期：IERS 每半年左右可能新增闰秒，硬编码旧表会导致漏判（如 2016 年末那次闰秒后，很多系统没及时更新表就无法识别）
- 混淆“闰秒时刻”和“闰秒区间”：闰秒只发生在那一秒（严格说，是那一秒的第 61 个有效秒），不是整个日期都“含闰秒标记位”——不存在“2016-12-31 是闰秒日”这种说法，只有 “2016-12-31T23:59:60Z” 这一时刻是闰秒
推荐轻量级做法：用现成库解析 leap-seconds.list
自己解析 leap-seconds.list 容易出错（格式有注释、字段顺序、过期行等）。更稳妥的做法是复用已验证的解析逻辑：
- C++ 可用
date库（Howard Hinnant 提供）：它内置了闰秒支持，通过date::utc_clock和date::tai_clock可做带闰秒的转换；调用date::utc_clock::to_sys(utc_tp)会自动处理闰秒偏移 - 若只需判断，可调用
date::utc_clock::to_utc_time(std::chrono::system_clock::now())得到带闰秒语义的 UTC 时间，再比对已知闰秒时刻（需自行维护列表） - 避免用
std::chrono::zoned_time直接查——它底层仍依赖系统时区数据库（tzdata），而 tzdata 不包含闰秒运行时判断能力
真正麻烦的从来不是“怎么写 if”，而是“怎么确保你用的闰秒表是最新、解析无误、且时间基准对齐”。这一步漏掉，后面所有逻辑都跑在流沙上。
