闰秒处理机制

wen IT资讯 2026-07-02 24

本文目录导读：

闰秒处理机制

闰秒是为了协调基于地球自转的世界时（UT1）与基于原子钟的协调世界时（UTC）之间的差异而引入的一种调整机制，由于地球自转速度不均匀（总体在减慢），原子时比天文时每年大约快约0.5至1秒，因此需要不定期地增加（或减少）一秒，使UTC与UT1的偏差保持在±0.9秒以内。

以下是闰秒的主要处理机制及其历史、现状和影响：

核心机制与实现方式

谁来决定：国际地球自转服务（IERS）负责监测地球自转速度，并决定何时插入或删除闰秒,闰秒会在6月30日或12月31日的最后一秒实施。
如何插入：闰秒有两种类型：
- 正闰秒（最常见）：在23:59:59之后插入一秒，变成23:59:60，然后进入第二天的00:00:00,这使这一天有86401秒。
- 负闰秒（从未发生过）：直接跳过23:59:59，从23:59:58 跳到 00:00:00，如果发生,这一天只有86399秒。
系统级处理：操作系统和网络时间协议（NTP，网络时间协议）客户端通常会处理这一秒，Linux内核的CONFIG_NTP_PPS 功能或特殊的时钟管理程序（如chronyd）会在接收到NTP服务器的时间信号后，在最后一秒将系统时钟重复或跳过这一秒，NTP服务器会在闰秒发生前的数十分钟内开始“涂抹”（slew）时间，即在较长一段时间内（如几小时）将这一秒的差异逐渐分散,以避免系统时间瞬间后退或前进。

尽管从天文和历法角度看，闰秒是必要的，但它对现代高精度、分布式计算系统造成了巨大困扰。

时间戳混乱：在23:59:60这一秒内产生的日志或数据，其时间戳是“60秒”，而许多数据库（尤其是老版本）、文件系统或编程语言时间库（如Java早期版本、旧版PostgreSQL）默认无法处理60秒这一值，可能导致记录被拒绝、异常或数据错乱。
系统挂起与崩溃：许多操作系统（尤其是Linux，如2012年闰秒导致的CrowdStrike类似事件）会在闰秒发生时执行内部时间更新操作，如果该操作阻塞了其他关键线程（如Java虚拟机中的System.currentTimeMillis()），可能导致整个系统无响应或高CPU占用，历史上曾多次有大型网站（如Reddit、Mozilla、LinkedIn、Qantas）因闰秒而宕机。
金融与卫星系统：金融市场对时间精度要求极高，哪怕1毫秒的偏差都可能导致交易顺序混乱，卫星导航系统（如GPS）使用自己的时间系统（GPS时），它只使用原子时，不包含闰秒，这意味着GPS时与UTC时之间有一个整数秒的偏移（目前为18秒）,航天器与地面站之间的通信也需要精确处理这个偏移。

由于上述问题，国际电信联盟（ITU）和计量界一直在激烈争论是否要废除闰秒。

2022年决议：在2022年的国际计量大会上，相关方最终决定：将在2035年之前废除闰秒，但这一决定并非立即生效,而是给出了一个过渡期。
替代方案：未来将采用更大的时间调整单位，例如闰分（在某个特定时间一次性插入或删除60秒，预计每50年一次）或闰时，这样，日常系统只需处理一次性的重大调整，而不是每年面临两次微小的、不可预测的秒级中断,这被认为对软件和网络系统更友好。
现状：截至2024-2025年），闰秒仍然存在，上一次插入闰秒是2016年12月31日，由于地球自转速度在2016-2023年间几乎没有明显减慢，IERS一直未宣布新的闰秒插入,但预计未来会再次出现。

使用NTP客户端：配置chronyd或ntpd，并启用闰秒涂抹（例如在chrony.conf中设置leapsecmode slew），这能让系统在数小时内微调时钟,而不是在最后一秒突然跳跃。
时间库升级：确保编程语言的标准时间库（如Java 8+的java.time、Python的datetime、Go的time）支持60秒的解析。
数据库处理：使用支持闰秒的数据库版本（如PostgreSQL 9.1+已能处理60秒的时间戳，但强烈建议避免在闰秒期间进行高并发写入），对于金融交易等关键系统，通常直接使用不带闰秒的GPS时或TAI（国际原子时）作为内部时钟,仅在显示时转换为UTC。
监控与准备：在已知的下一个闰秒发生前（目前暂无确切计划），应提前进行压力测试，确保所有依赖时间戳的服务（如TTL缓存、日志、调度器）不会因此崩溃。

一句话总结：闰秒是为了让原子钟时间与地球自转同步而插入的额外一秒，它曾多次导致大型互联网服务宕机，因此国际社会已决定在2035年前废除它，转而采用更罕见的、影响更小的大幅度调整，系统管理员应通过“时间涂抹”来平稳处理闰秒。