std::chrono::leap_second 不存在于 C++20 或任何已发布标准中，是误传或私有扩展；C++20 仅引入 tai_clock 和 utc_clock，闰秒需用户手动处理。
std::chrono::leap_second 在 C++20 中不可用
直接说结论：std::chrono::leap_second 并不存在于任何已发布的 C++ 标准中，包括 C++20 和 C++23。它从未被标准化委员会采纳，也没有出现在 ISO/IEC 14882 的正式文本里。你如果在某些文档、博客或实验性编译器头文件里看到这个名字，大概率是误传、草案残留、或某家编译器（如早期 libc++ 实验分支）的私有扩展，但不是标准接口。
为什么你会搜到 leap_second 相关内容
这个混淆主要来自几个地方：
- C++20 引入了
std::chrono::tai_clock（国际原子时）、std::chrono::utc_clock（协调世界时），而 UTC 和 TAI 之间差值的核心就是闰秒 —— 于是很多人自然推测应该有个leap_second类型来建模单次闰秒事件； - ISO C 标准（如
<time.h></time.h>）和 POSIX 有struct tm的tm_leap字段（极罕见且非便携），部分 C++ 文档错误映射到了std::chrono； - 某些 RFC（如 RFC 5905）或 NTP 实现里用 “leap second indicator” 表示即将插入/删除闰秒的状态位，但这属于协议层语义，不是 C++ 时间类型。
实际处理闰秒的可行路径
目前 C++ 标准库不提供闰秒表、不自动修正 UTC 时间、也不暴露闰秒发生时刻。所有闰秒相关逻辑必须由用户自行管理：
- UTC 时间计算默认忽略闰秒：例如
std::chrono::utc_clock::now()返回的是“平滑 UTC”（即按 SI 秒连续计数，不跳变），它与真实 UTC 的偏差会随闰秒累积（当前约 +37 秒）； - 若需对齐 IERS 公布的闰秒表（如 leapsecond.dat），得手动解析该文件，构建查找表，并在转换
utc_clock↔system_clock或tai_clock时做偏移修正； - 注意
std::chrono::utc_clock的实现依赖系统支持：Linux 上通常基于clock_gettime(CLOCK_REALTIME)，而内核本身不区分闰秒，所以返回值仍是“无闰秒 UTC”； - 跨平台一致性极差：macOS 和 Windows 完全不提供
utc_clock或tai_clock的可用实现（libc++ 和 MSVC 标准库至今未完成这部分）。
一个最小可验证的现实提醒
运行这段代码：
立即学习“C++免费学习笔记（深入）”；
#include <chrono>
#include <iostream>
int main() {
using namespace std::chrono;
// 下面这行在 GCC 13 / Clang 16 / MSVC 19.3x 上全部编译失败
// utc_clock::time_point tp = leap_second{}; // ❌ error: 'leap_second' was not declared in this scope
std::cout << utc_clock::now().time_since_epoch().count() << "\n";
}
你会发现连最基本的存在性都得不到保障。真正要处理闰秒，得靠外部数据源 + 自定义时钟适配器，而不是幻想标准库会替你封装那个“缺失的类”。最常被忽略的一点是：即便你实现了完整闰秒修正，NTP 客户端、系统时钟同步机制、日志时间戳采集链路，也几乎都不参与闰秒对齐 —— 所以单点修正往往意义有限。
