如果时钟在23:59:59之后，显示的不是零点，而是23:59:60，你会认为它坏了吗？这个看起来像程序错误的时间，曾经是协调世界时的一部分。它叫闰秒，是人类为了让原子钟与地球自转保持接近而设置的调整。如今，国际计量大会决定让这项运行半个多世纪的机制退出日常UTC调整。
新闻里的“取消闰秒”，既是计量制度变化，也是一次基础设施规则更新。对普通人，手表不需要因此拨快一小时；对程序员，未来少了一类不连续风险，却仍然要处理校时、时区、历史数据和多设备同步。本文截至2026年10月27日核对一手资料，采用AI辅助编辑；封面为AI生成概念插画，其余为原创教学图，不是真实原子钟照片或实测数据。
先说清楚：取消的是什么，什么时候生效
2026年第28届国际计量大会通过的第5号决议明确：连续协调世界时将于2027年5月20日生效，地球自转时间UT1与UTC之差的最大允许绝对值放宽到3600秒，即1小时。其目标是让UTC在未来数百年的尺度上保持长期连续。
此前，2022年第4号决议决定在2035年或之前扩大UT1与UTC的允许差值，并要求制定新上限及实施方案。2026年决议给出了更早的具体生效日期和新的上限。因此，还在引用“2035年才取消”的文章，需要检查其信息是否停留在上一阶段。
| 需要区分的事项 | 正确理解 |
| 决议通过 | 国际计量规则作出了明确决定 |
| 生效日期 | 2027年5月20日起实行连续UTC |
| 3600秒上限 | 允许UTC与UT1逐渐产生更大差值 |
| 当天钟表操作 | 不意味着把所有时钟跳变一小时 |
| 历史数据 | 已经发生的闰秒仍然属于历史事实 |
截至本文核对，美国海军天文台闰秒公告页显示2026年12月底不插入闰秒，最近一次正闰秒发生在2016年12月底。这里要区分“未来停止调整的制度安排”与“某个具体月底是否插入”的业务公告，不能自己给剩余过渡期安排一次跳秒。
地球转一圈，与原子钟数一天，为什么不完全一样
人类最熟悉的时间来自日出日落，但地球自转并非匀速机械齿轮。它受大气、海洋、地球内部运动及潮汐等因素影响，转速会变化。用地球自转建立的时间尺度，天然包含这些变化；现代精密计时则需要更稳定、可复制的单位。
原子计时把秒与稳定的原子物理过程联系起来。这里的稳定，并不意味着每一台仪器完全没有误差，而是可以通过测量、比对和统计构建可靠时间尺度。计时单位的定义、实验室实现和向用户发送时间信号，是三个相关但不同的层次。
为了理解新闻，先记住三个名字。UT1描述地球自转角度对应的时间；TAI是国际原子时；UTC是协调世界时，也是民用计时的重要国际参考。它们都叫“时间”，却承担不同任务，不能把一个系统中的数值直接当成另一个系统的数值。
| 时间尺度 | 主要参照 | 适合解决的问题 |
| UT1 | 地球实际自转 | 地球朝向、天文与相关定位计算 |
| TAI | 国际原子计时体系 | 连续的原子时间参考 |
| UTC | 与原子时同速、历史上用闰秒协调 | 民用授时与国际时间参考 |
根据NIST闰秒说明，当前TAI领先UTC 37秒。这个偏移不是手机走慢37秒，也不会因为取消未来闰秒就在生效日清零。历史上的UTC调整与早期偏移共同形成现有关系，不能把“37秒”误说成自1972年以来插入了37次闰秒。
现实中，设备通常接收某个授时机构或服务实现的时间。它与理想参考的差别，需要用偏移、稳定性和不确定度描述。取消闰秒不会让普通晶振自动变成原子钟，网络延迟与设备漂移也仍然存在。
闰秒这块补丁，究竟补在哪里
旧机制通过调整UTC，使它与UT1保持在较小差值范围内。注意，补丁作用于时间尺度的表达与协调，并不是让地球突然加速，也不是让物理世界凭空多出一秒。一天的自转长度与民用时间标签，是两个不同层面的问题。
正闰秒发生时，UTC时间标签可以经历23:59:59、23:59:60，然后进入次日00:00:00。这个序列中多了一个带“60”的秒标签；它不是常规分钟里的另一个普通写法。对只接受00至59的解析器而言，这就成为特殊输入。
负闰秒方向相反，需要跳过一个秒标签。按照这种机制的示意，末尾可以从23:59:58直接进入次日00:00:00。正闰秒与负闰秒不是把日期减一天，也不是取消一个闰年；它们的粒度、目的和触发依据都不同。
这里画的是UTC标签。换成其他时区，特殊秒可能出现在当地上午或其他时刻。工程系统不能只在本地午夜设置一个特殊分支，就认为已经覆盖全球。对接接口时，必须知道字段代表UTC、带偏移的当地时间，还是另一种时间尺度。
闰年则是历法与年长之间的协调，仍然独立存在。2027年连续UTC生效，不意味着以后没有2月29日；夏令时和时区政策也不会随之自动消失。将这些制度统称为“时间补丁”，便于科普，却不能在程序逻辑里当成同一个规则。
一秒钟很小，为什么数字系统会觉得麻烦
人看钟表，可能根本没有注意到这一秒；系统却会在这一秒内进行大量排序、到期判断、重试、计费和写入。只要某个组件假设“每分钟永远只有60个普通标签”，特殊输入就可能暴露解析或边界问题。
更复杂的是同一事件经过多个系统。采集器接受特殊时间，消息中间件不接受；数据库将它规范化，审计系统保留原始字符串；另一套服务又采用平滑校时。每个组件单独看似工作正常，组合后却可能出现标签重复、无法比较或时间差异常。
举一个虚构例子：订单服务根据墙上时间计算五秒超时，在时钟被调整后，等待可能比预期更长或更短。再如，同一设备在不同记录中保存了本地时间与UTC，却没有记录偏移，排障人员会误判事件先后。问题不必等到闰秒才出现，普通校时也可能触发类似后果。
因此，取消闰秒减少的是一类全球协调调整，不是宣布时间系统从此没有异常。网络失联、虚拟机迁移、硬件漂移、管理员修改时钟和时间服务配置错误，都仍可能影响应用看到的墙上时间。
对开发者而言，这项决议的价值在于让未来UTC更适合作为连续参考，而不是替应用保证所有时间字段可靠。计量规则、操作系统时钟、授时链路和业务语义，需要分别审查。
负闰秒与平滑时间，让问题更不适合继续拖延
本次决议明确讨论了负闰秒风险：这种调整此前没有实际应用，而关键基础设施需要为潜在影响做准备。地球自转的近期变化，使“以后只可能加一秒”成为不可靠假设。这里不应把风险评估改写成已经确定的负闰秒日期。
为避免突变，一些服务商采用闰秒平滑，即把一秒调整分散到一段时间中。它让设备看到的时间连续变化，但平滑窗口、函数和起止点如果不一致，不同授时源在同一时刻可能给出不同结果。
Google的Leap Smear文档介绍了其推荐的24小时线性平滑方案。这个具体实现可以帮助理解原理，但不能据此认定所有云平台、所有设备都采用同样策略。在平滑期间，这种时间与未平滑UTC存在暂时差异；它不是让差异凭空消失。
对多云或多设备系统，混用不同语义的时间源可能比单机是否接受“60”更难发现。文档里只写“使用NTP”还不够，还应知道服务提供的是哪种参考、是否平滑、切换来源时如何处理差异。
连续UTC生效后，与未来闰秒有关的平滑需求会改变，但不要今天就凭新闻删除生产配置。应遵循授时提供方与设备厂商的实施说明，确认客户端、服务端和历史处理逻辑的更新范围。规则统一是一项协同迁移，不是一个开关能覆盖全部系统。
放宽到一小时，会不会导致太阳与钟表彻底脱节
新的3600秒是最大允许差值，不是立即引入的偏移。把上限从接近一秒放宽到一小时，可以让UTC较长时间不必追随地球自转的小变化。UT1仍然被观测，相关差值也仍然有实际用途。
我们本来就不要求每个城市在钟表12点时太阳恰好经过当地子午线。时区覆盖广阔地域，民用钟表与当地太阳位置之间存在制度和地理差别。连续UTC进一步明确了两类需求：社会系统需要统一稳定的时间参考，部分科学计算需要地球实际朝向。
两类需求可以通过明确转换共同满足。天文观测、大地测量和相关航天任务，应使用对应的地球定向数据及算法，而不是永远假定UTC与UT1只差不到一秒。需要的是更新输入和边界条件，不是停止测量地球自转。
也不要把新闻理解成“已经规定未来每隔多少年加一个闰小时”。本次决议给出了连续UTC与差值上限，并没有提供一个可直接写入日历的固定闰小时周期。地球变化与未来制度决策都不适合由一条直线外推出精确日期。
普通公众的直接动作更简单：关注设备与服务正常更新时间，无须自行改变时区或把时钟平移一小时。擅自操作只会制造一个比待取消闰秒大得多的错误。
历史时间戳为什么不能删掉重算
停止未来插入闰秒，不等于取消过去已经发生的事件。2016年底的特殊秒仍然存在于历史记录、科学数据和相关转换表中。历史数据的解析、重放与跨尺度换算，仍需保留适当支持。
RFC 3339对时间戳表示及闰秒的适用条件有专门讨论。标准允许某种表达，并不保证所有语言库、数据库和API都实现它。格式、解析能力和实际存储语义，应分别验证，不能只在接口说明里写一个标准名称。
Unix时间也不能简单理解成“从1970年开始经过的所有SI秒毫无遗漏地累加”。常见POSIX语义排除了闰秒，具体平台还存在边界行为。Python时间模块文档同样说明了这一点。因此，两个时间戳直接相减所得数值，是否等于目标任务关心的物理时长，要看时间尺度和实现。
对普通业务，可以采用清楚一致的UTC时间戳约定；对高精度实验或历史事件重建，可能还需记录原始尺度、转换表版本和采集设备信息。没有统一适用所有系统的“一个整数解决全部时间问题”。
数据迁移时，应保留原始值与转换依据，先在副本上验证。不要把识别不了的历史特殊秒直接替换成下一天零点后覆盖原记录，否则会丢失信息；也不要对整库统一加减37秒，试图“修正”所有时间，那是在混淆尺度和历史偏移。
程序员现在就能做的第一件事：区分时刻与时长
“订单何时创建”需要可与外部系统对应的时间；“这个函数运行多久”需要稳定的间隔测量。两者虽然都使用秒，但不应默认使用同一类时钟。墙上时间用于表达时刻，单调时钟更适合本机运行期间的超时和耗时。
下面示例同时记录UTC标签与单调性能计数器，只演示测量分工，不修改系统时钟。它没有生成性能结论，也没有模拟真正的闰秒服务。
from datetime import datetime, timezone
from time import perf_counter_ns
started_at = datetime.now(timezone.utc).isoformat()
begin = perf_counter_ns()
result = sum(range(1000))
elapsed_ns = perf_counter_ns() - begin
assert result == 499500
assert elapsed_ns >= 0
print({"started_at": started_at, "elapsed_ns": elapsed_ns})需要注意，纳秒单位不等于纳秒级准确度。计数器分辨率、调度和硬件都会影响测量。单调计数值也不是通用UTC时间戳，不能拿两台独立设备的原始读数直接比较先后；暂停、重启及跨进程语义应查对应平台文档。
对于分布式排序，更不能期待几个小数位足够多的物理时间戳自动证明因果关系。应结合事件ID、来源、序号和业务状态，必要时采用明确的逻辑顺序。时钟误差范围重叠时，就应该承认先后可能不确定，而不是强行从字符串排序得出结论。
一个“日志倒序”的例子
假设服务先记录业务步骤甲，再记录步骤乙，中间发生一次向后校时。日志中的乙可能比甲更早，但这并不意味着业务真的逆向执行。排障时，应结合请求ID、步骤序号、单调耗时及授时状态，而不是先删除看起来“不合理”的记录。这个例子是说明校时语义，并不声称所有平台处理闰秒都采用向后跳变。
再假设两台机器报告的事件只差几毫秒，但各自误差范围比这个差值更大。仅凭时间戳无法可靠确定先后。若任务必须保证唯一顺序，应由业务协议、队列或其他明确机制提供，而不是把时间字段增加到更多小数位。显示位数、分辨率与准确度是不同概念。
取消未来闰秒以后，这些问题仍然成立。连续UTC减少了参考尺度上的一类调整，却没有让每台设备与参考完全重合。正确设计应同时保留可比较的时刻、适当的间隔测量和必要的业务顺序，不把所有责任压到一个日期字符串上。
从服务器到采集设备，迁移时具体查哪些地方
先画授时链路：上游时间服务、内部NTP或PTP设施、操作系统、虚拟化环境、应用和终端。每一段记录负责人、设备或软件版本、时间尺度、校正策略和故障切换方式。这里提到协议不代表所有设备支持相同精度，最终能力取决于实现与实际网络。
数据库与日志系统重点检查解析、排序、去重和区间查询。应用重点检查超时、缓存到期、预约和定时任务。设备重点检查失联保持、重启后校时、时间源切换与多路数据对齐。取消闰秒只是共同背景，各层的验收目标并不一样。
多设备采集系统尤其需要追问“时间戳标的是哪个时刻”。一张图像上的时间，可能代表传感器曝光、驱动接收、算法完成或文件落盘；即使全部使用同一时间参考，这些时刻也不同。提高校时精度不能自动消除管线延迟。
例如两台相机和一个位置传感器共同记录一次运动，应保存设备身份、采样序号、时间戳来源和已知延迟。若某设备给UTC，另一设备给开机计数，必须建立映射并跟踪漂移。把它们都显示为“毫秒”并没有完成同步。
测试可以在隔离环境中覆盖普通校时、时间源失联、恢复、重启、边界解析和历史数据重放。检查指标包括偏移、漂移、事件顺序一致性和异常处理。不要为了演练，随意修改线上数据库主机或关键采集设备的时间。
通过标准也应可检查：时间源可追溯，策略一致，设备状态可见，日志能关联，关键业务在异常条件下仍有清楚行为。仅凭“机器右下角时间看起来一样”无法证明这一点。
时间接口也需要一份合同
接口至少说明时间尺度、单位、精度约定、时区或偏移、产生位置和未知值处理。设备发送一个整数时，应解释它是UTC相关纪元时间、设备开机计数，还是采样序号；发送小数时，应说明小数部分表示秒、毫秒还是其他单位。字段名字叫timestamp，不构成完整说明。
事件发生时间与接收时间最好分开。前者描述设备或业务认为何时发生，后者描述平台何时收到。网络排队、断线重传和批量上传都会拉大两者差异；如果只保存接收时刻，就很难恢复真正的采样顺序。对时间不可靠的设备，还应保留同步状态或质量标记。
本地预约也需要独立语义。“每天当地上午九点执行”与“每隔二十四小时执行”不完全相同，跨时区或涉及夏令时的系统尤其如此。连续UTC不会替应用决定使用哪一种。需求文档应先给出业务定义，程序再选择时区规则与调度方法。
错误处理同样要约定。接口遇到不支持的历史特殊秒，是明确拒绝、保留原始值等待专门转换，还是采用经过说明的规范化方式，应可追踪且能复现。最差的做法是悄悄改值，然后让下游以为它拿到了未经修改的原始时间。
一张小清单，帮团队把新闻变成可执行工作
第一步，把时间字段分类：业务时刻、持续时间、设备计数、当地预约分别是什么。第二步，梳理读取和写入路径，确认是否有隐藏转换、无时区字符串或不同平滑来源。第三步，核对供应商针对连续UTC的说明与软件支持计划。
第四步，建立包含历史闰秒与异常校时的测试样本，并保留预期行为。第五步，按风险分阶段更新，观察时间源状态与业务指标。第六步，维护兼容与回退方案，确保恢复旧软件时不会意外混用另一套时间策略。
对于普通网站，这可能只是一次依赖与运维审查；对于电力、通信、金融或科学采集，可能涉及更完整的授时链和验收。不能因为国际规则统一，就推断每台旧设备已经理解新规则；也不能因为行业要求不同，就让同一个系统内部出现无人解释的多种时间语义。
可以用三轮问答检查实施是否完成。第一轮问运维：当前参考来自哪里，失联后设备怎样保持，切换来源是否可能改变策略？第二轮问开发：哪些功能依赖墙上时间，超时是否使用合适时钟，历史特殊值怎样解析？第三轮问业务：乱序、过期或重放发生时，怎样判断结果是否可接受？
如果答案仍是“系统一直这样运行”，说明缺少可验证说明。团队可以先选择一条重要链路，把输入、转换、存储、显示和回放串起来检查；确认后再扩展到其他服务。这样比只更新一个授时地址、更换一台设备后宣布全系统完成更容易发现遗漏。
普通读者还会问的几个问题
取消闰秒会让一天变短吗？需要区分民用标签与地球自转。改革改变的是两种时间尺度的协调方式，不会改变地球物理运动。不要把少一次人为插秒，理解成所有人的寿命自动减少一秒，更不用给日历中的每一天统一减去一秒。
北京时间要改变吗？这项决议针对UTC连续性，并没有宣布中国改变民用时区。日常设备仍应按照相应时间服务和时区设置工作。用户自行把UTC与当地时间的偏移改成另一个数值，不是落实改革，而是在制造新的转换错误。
以后能不能删除闰秒表？对于只处理未来普通业务的组件，维护方式可能改变；但历史转换、旧数据重放和科学计算仍可能需要相关记录。是否可以精简某段逻辑，应根据数据范围和兼容要求决定，不宜把一条全球新闻直接变成全仓库删除指令。
连续UTC是不是重新定义了秒？不是同一件事。本次第5号决议讨论时间尺度的连续性；秒作为计量单位的定义及其未来演进属于另一议题。把计时单位、时间尺度和授时协议分别理解，才能知道某次变化到底影响代码的哪一层。
这次变化最值得记住的，不是“我们以后少活一秒”，而是时间参考开始更清楚地服务不同需求。原子计时提供稳定尺度，地球观测描述真实转动，软件负责把标签、测量和业务关系准确连接起来。把这些层次分清，远比在代码里多写一个特殊判断更重要。
“逝者如斯夫，不舍昼夜。”——孔子，《论语·子罕》
资料说明：决议与时间数据以所链接官方来源为准，核对日期为2026年10月27日；工程例子为原创教学设计，未修改任何生产授时配置。示意图没有预测未来具体闰秒或闰小时日期。
转载自 CSDN-专业IT技术社区
原文链接：https://blog.csdn.net/qq_17456539/article/details/169241129
