閏秒說明：UTC 如何與地球自轉保持一致
閏秒是插入到 UTC 中的一秒調整，用來讓原子鐘時間與日益變慢的地球自轉保持一致。它曾讓大型系統崩潰，並計畫在 2035 年前廢除。本指南講解它是什麼、Unix 時間如何處理它（大多是忽略），以及系統為保持安全所採用的實用模式。
一分鐘看懂閏秒
閏秒是偶爾添加到 UTC 的額外一秒，用來把時鐘時間保持在 UT1 的 0.9 秒以內 —— UT1 是由地球實際自轉定義的時間。原子鐘以完全穩定的速率走動，但地球並不以完全穩定的速率自轉，於是兩者漸行漸遠，必須重新同步。自 1972 年以來共有 27 次這樣的插入，最後一次在 2016-12-31，而世界各計量機構已投票決定在 2035 年前廢除它們。關鍵在於：Unix 時間完全忽略閏秒。下表顯示主要時間標度之間的關係。
| 時間標度 | 基於 | 閏秒? | 備註 |
|---|---|---|---|
| TAI | 原子鐘（SI 秒） | 從不 | 連續 —— 自 2017 年起領先 UTC 37 秒 |
| UT1 | 地球自轉（天文） | — | UTC 保持接近的太陽時 |
| UTC | TAI，向 UT1 微調 | 是（至 ~2035） | 全球民用時間 |
| Unix 時間 | UTC，但每天 86,400 秒 | 忽略 | 應用程式碼所用 |
什麼是閏秒？
閏秒是添加到 UTC 的額外一秒，用來把它保持在 UT1 的 0.9 秒以內 —— UT1 是基於地球自轉的天文時間。地球自轉並不規則，並在長時間尺度上略微變慢，於是原子的 UTC 和自轉的 UT1 漸行漸遠，必須重新對齊。
- 1972 年至最後一次（2017-01-01）之間共插入 27 次正閏秒
- 從未發生過負閏秒，但若地球加速，理論上是可能的
- IERS 的 Bulletin C 至少提前六個月公告即將到來的閏秒
- 插入在 UTC 一天的最末尾（23:59:60），通常在 6 月 30 日或 12 月 31 日
為什麼會有閏秒
UTC 於 1972 年被重新定義為一種混合體：SI 秒（原子），透過偶爾插入閏秒而保持在 UT1（天文）的幾分之一秒以內。目標是讓時鐘時間與太陽時大致對齊，而不必固守任一純粹體系。
- TAI：國際原子時，一種沒有閏秒的純 SI 秒計數（目前領先 UTC 37 秒）
- UT1：自轉時間，基於地球姿態觀測
- UTC：混合體 —— 原子的滴答，週期性地向 UT1 靠攏
- 若沒有閏秒，UTC 與太陽每世紀會偏離約 1 分鐘
閏秒與 Unix 時間
POSIX Unix 時間被定義為忽略閏秒：每個 Unix 日恰好是 86,400 秒。當閏秒發生時，不同系統處理方式各異 —— 沒有一個會把 Unix 時間戳額外加一秒。這就是為什麼 Unix/POSIX 時間戳跟隨 UTC，卻不是自 1970 年以來流逝的真實物理秒數的計數。
- 嚴格 POSIX：秒號重複 —— 23:59:59 出現兩次，二者對應到同一個 Unix 時間戳
- 2012 年前的 Linux 核心：實作嚴格 POSIX；浮現許多 bug（Java、MySQL、Hadoop 當機）
- 現代 Linux 核心：透過 clock_settime() 套用調整；某些實作在一個視窗內做平滑
- 平滑：把額外一秒分攤到數小時或一天，使任何一秒都不會被重複
Leap smearing（閏秒平滑）
大多數大型公共 NTP 服務不再把閏秒原樣傳給用戶端。它們做平滑：把額外一秒分攤到一個視窗，使用戶端時鐘在視窗期間比 UTC 走得極其略快（負閏秒則略慢）。結果是沒有任何用戶端會看到 23:59:60 —— 代價是短暫偏離嚴格的 UTC。
| 提供方 | 平滑視窗 | 備註 |
|---|---|---|
| 24 小時，以 UTC 午夜為中心 | 約 11.6 µs/s 調整 | |
| AWS | 24 小時 | Amazon Time Sync Service |
| Meta（Facebook） | 17 小時 | — |
| Microsoft | 24 小時 | 自 2018 年起 |
- 平滑意味著用戶端掛鐘在平滑視窗期間偏離嚴格的 UTC —— 用於應用沒問題，但不適合高精度計時
會有負閏秒嗎？
迄今為止每一次閏秒都是正的 —— 增加一秒。但自約 2020 年起，地球轉得比過去大半個世紀都略快，短暫地把曾經只是理論的負閏秒前景抬了出來：移除一秒，使 23:59:58 之後直接是 00:00:00。那將是史上首次，而許多能處理重複一秒的系統，仍會錯誤處理被跳過的一秒。近期研究表明，極地融冰正在減緩這種加速，可能把任何負閏秒延後到 2029 年左右 —— 到那時 2035 年的廢除或許已讓它變得無關緊要。
2035 年的廢除
國際計量大會（CGPM）於 2022 年 11 月（第 4 號決議）投票決定，最遲在 2035 年前從 UTC 中取消閏秒。該計畫用一個大得多的容差取代 ±0.9 秒的 UT1 容差，實際上讓 UTC 在數十年間偏離太陽時。
- 2022-11：CGPM 第 4 號決議 —— 在 2035 年或之前增大 UT1−UTC 的最大差值
- 2023-11：ITU-R WRC-23 正式認可該計量決定
- 廢除後，UTC 將成為一個以固定偏移與 TAI 綁定的純原子時間標度
- 各實作有到 2035 年的時間來逐步淘汰處理閏秒的程式碼路徑
相關參考
FAQ
- 至今有過多少次閏秒？
- 1972 年至 2017-01-01 之間，UTC 共插入了 27 次正閏秒。此後再無。從未發生過負閏秒。
- UTC 和 TAI 有什麼區別？
- TAI 是沒有閏秒的連續原子時間；UTC 是經閏秒調整、以保持在地球自轉 0.9 秒以內的 TAI。自 2017 年起，TAI 恰好領先 UTC 37 秒。
- 會有負閏秒嗎？
- 有可能，但從未發生。自約 2020 年起地球轉得略快，原則上可能需要移除一秒而非增加一秒。計畫於 2035 年廢除閏秒，可能使這個問題變得無關緊要。
- 2035 年後 Unix 時間戳會包含閏秒嗎？
- 不會。Unix 時間從未計入閏秒，今後也不會。廢除之後，UTC 自身停止添加閏秒，於是 Unix 時間與 UTC 將直接保持一致。
- 為什麼 Reddit 和 Cloudflare 在閏秒當天崩潰？
- Linux 核心和 Java 函式庫存在會在出現 23:59:60 時觸發的 bug —— 通常是無窮迴圈、鎖競爭，或某些程式碼路徑中因「負秒」導致的 NaN 運算。
- 目前 TAI−UTC 偏差是多少？
- 37 秒。即 27 次閏秒（自 1972 年）加上定義 UTC 時設定的 10 秒初始偏移。