C++标准库不支持闰秒判断，必须依赖IERS闰秒表手动查表；std::time_t隐式跳过闰秒，system_clock无法识别23:59:60，正确做法是解析leap-seconds.list并比对UTC插入时刻。
闰秒在C++中没有标准库函数直接判断
标准C++（包括std::chrono、std::tm、std::put_time等）完全不感知闰秒。所有时间点都被建模为连续的TAI或UTC线性刻度，但ISO C++标准明确将闰秒视为“未定义行为”——std::mktime、std::gmtime等函数在遇到23:59:60这样的秒值时，行为由实现决定，通常直接拒绝或截断。这意味着你不能靠std::chrono::system_clock或std::time_t的常规转换来检测某日是否含闰秒。
必须依赖外部闰秒表 + 手动查表
国际地球自转服务（IERS）每半年发布一次闰秒公告，所有可靠判断都基于已知生效的闰秒列表。你需要：
- 维护一份权威闰秒表（如IERS发布的
leap-seconds.list，格式为“TAI-UTC 秒数 有效期起始TAI秒”） - 将目标日期（如
"2016-12-31"）转换为UTC时间点（注意：不是std::time_t，而是需对齐到IERS定义的UTC历元） - 检查该UTC时刻是否恰好落在某次闰秒插入的“末尾时刻”——即UTC时间的
23:59:60（仅存在于闰秒发生当日的最后1秒）
例如：2016年12月31日23:59:60 UTC是真实存在的，对应TAI时间2017-01-01 00:00:37 TAI（因TAI-UTC = 37）。判断逻辑不是“这天有没有闰秒”，而是“这个精确UTC秒级时间点是否等于某次闰秒的插入时刻”。
实际编码中容易踩的三个坑
用C++处理闰秒最常出错的地方不在算法，而在数据对齐和类型误用：
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
立即学习“C++免费学习笔记（深入）”；
-
std::time_t通常实现为Unix时间戳（自1970-01-01 00:00:00 UTC起的秒数），它**隐式跳过所有闰秒**。2016-12-31 23:59:60 UTC在std::time_t中根本无法表示——mktime会返回-1或把60秒强制归为下一分的第一秒 - 不要用
std::chrono::system_clock::to_time_t反推闰秒：该转换假设UTC连续，结果必然丢失闰秒边界 - IERS的
leap-seconds.list中时间以TAI为基准，而你的输入是UTC日期字符串。必须用已知的TAI-UTC偏移差（如2024年为37秒）做换算，且注意该偏移在每次闰秒后+1——不能硬编码
一个最小可行示例：读取leap-seconds.list后，对每个条目解析出UTC生效时间（如"2017-01-01 00:00:00"），再比对目标日期是否完全匹配该日期且时间部分为"23:59:60"（需手动解析字符串，不可走strptime）。
生产环境建议用成熟库而非手写
自己维护闰秒表和解析逻辑极易出错。更稳妥的做法是接入已验证的第三方库：
-
libtai：专为TAI/UTC/UT1转换设计，内置闰秒表更新机制，提供tai_utc等函数直接查表 -
ctpp或date.h（Howard Hinnant's date library）：后者支持自定义闰秒表，可通过date::utc_clock进行带闰秒的转换，例如date::utc_clock::from_sys可显式暴露闰秒边界 - 若用C++20，
<chrono>新增了utc_clock，但标准未强制要求实现闰秒支持——GCC/libstdc++目前仍不支持，Clang/LLVM也仅实验性；切勿假设std::chrono::utc_clock已可用
真正棘手的从来不是“怎么写个if判断”，而是“如何确保你用的时间源、转换链、闰秒表版本三者严格同步”。哪怕只差一次IERS更新，就可能把关键系统日志的时间戳错位整秒。
