← 返回 Siami 首頁

BIPM 正式表決:閏秒走入歷史 2027 年 5 月 20 日起 UTC 連續不中斷

▲ 100 💬 49
BIPM 正式表決:閏秒走入歷史 2027 年 5 月 20 日起 UTC 連續不中斷

編按:本文綜合整理自 BIPM 官方決議 5 (2026)、Hacker News 熱門討論(168↑ / 77 留言)、Nature 期刊報導、Meta 工程團隊部落格、WEF 與 timeanddate.com 分析,並加入 Siami 編輯部觀點與數據解讀。

事件:BIPM 拍板,53 年閏秒機制走入歷史

國際度量衡局(BIPM)於 2026 年 10 月 15 日召開的第 28 屆國際度量衡大會(CGPM)上,正式通過決議 5:自 2027 年 5 月 20 日起,協調世界時(UTC)將成為完全連續的時間尺度,不再新增或刪除閏秒。這是自 1972 年以來實施 53 年的閏秒機制首次走入終點。

決議同時規定:

  • UT1 − UTC 最大差值放寬至 3,600 秒(1 小時),確保 UTC 連續至少數個世紀不再被打斷
  • 2035 年前完成過渡,2040 年前所有無線電通訊系統完成更新
  • 由 BIPM、國際電信聯盟(ITU)、國際天文學聯合會(IAU)、國際地球科學聯合會(IUGG)與國際地球自轉與參考系統服務(IERS)共同執行

自 1972 年至今,全球已累計插入 27 次正閏秒,這 27 秒將是人類文明史上最後的閏秒。


為什麼是現在:負閏秒風險迫在眉睫

決議背後最直接的推力是「負閏秒」逼近。負閏秒是指地球自轉加速到原子鐘跑得太慢,必須把某一分鐘從「60 秒」縮成「59 秒」。這在 53 年歷史上從未發生過。

2025 年 3 月由 CCTF(時間頻率諮詢委員會)與 IERS 共同舉辦的專家工作坊估算:

  • 2035 年前出現負閏秒的機率約 30%
  • 從未實施過的負閏秒被視為「對關鍵基礎設施造成嚴重故障的高風險事件」
  • 整改所需的財務投資與 Y2K 千禧蟲危機規模相當

決議文中特別指出,IoT 物聯網、分散式多感測器系統、智慧電網等新興架構讓任何閏秒插入的風險都顯著放大,特別是負閏秒。全球大型雲端服務商(如 Google、Meta、Amazon)為了避免時間階梯,各自發展不同緩解方法,反而導致系統間時間不一致、不符合 SI 國際單位制。

「工業使用者與國家關鍵基礎設施(交通、能源配送、電信、太空任務)的同步需求,要求 UTC 必須是連續的、未來不再調整。」 — BIPM 決議 5 (2026) 原文


為什麼這件事重要:科技文明的時間錨點位移

這不是普通的技術決議。從 1967 年以來,人類社會的每一秒、每一個時戳、每一筆交易、每一張合約都依賴 UTC 與地球自轉的微弱連結。當這個連結被切斷,時間的本質發生變化:

  • 歷經千年,UTC 與「太陽在天空中的位置」將開始偏離。在數千年後,午時(中午 12:00)可能對應到當地太陽時的下午 5 點
  • 軟體工程師不再需要處理閏秒 — 這個曾讓 Reddit、LinkedIn、Cloudflare 大規模故障的元凶即將消失
  • 太空任務、衛星導航、金融交易、5G/6G 同步將更加可靠 — 連續時間尺度讓分散式系統的時序一致性大幅提升
  • 法規與合約的時間戳記將純粹依賴原子鐘 — 法律層面的「時間」定義將更接近 SI 物理定義

然而,反對聲音同樣存在。部分天文學家與哲學家認為,這等於「把人類的時間從太陽身邊拉開」,未來世代若想找回真實的太陽時,可能需要複雜的轉換。


數據解讀:閏秒的 53 年小歷史

指標數據
首次閏秒實施1972 年 6 月 30 日
累計正閏秒次數27 次
最近一次閏秒2016 年 12 月 31 日
連續 UTC 生效日2027 年 5 月 20 日
UT1-UTC 最大容許差3,600 秒(1 小時)
過渡期截止2035 年(最遲 2040 年)
2035 年前負閏秒機率約 30%

值得關注的是,決議的時間表比 2022 年 CGPM 決議 4 的「2035 年前完成」足足提前 8 年。這顯示 BIPM 對負閏秒的恐懼比預期更強。從 Reddit 程式設計師社群(r/programming)到 Hacker News 主流討論,技術圈對這項決定普遍歡迎,認為「早該如此」。

不過,決議並未強制各國時區政策調整。時區與夏令時間仍由各國自行決定 — 中華民國(台灣)仍維持 UTC+8 的國家標準時間,但內部使用 UTC 連續計算的金融市場與 5G 同步網路,將不再受到 2035 年後潛在閏秒的影響。


業界反應與未解問題

  • Meta:2022 年公開支持廢除閏秒,理由是「無法預測的時間階梯讓分散式系統難以設計」
  • Google:自 2010 年代起在自家基礎設施實施「閏秒抹平」(leap smear),把額外的一秒分攤到 24 小時內
  • Amazon AWS:採取「閏秒凍結」策略,必要時讓 EC2 時間短暫落後真實時間
  • Cloudflare:曾在 2017 年因閏秒導致 DNS 查詢失敗,公開呼籲廢除

未解的問題包含:

  • 數千年後若 UTC 與太陽時差異過大,是否要採用「閏小時」機制?目前無國際共識
  • 各國法律對於「時間」的定義是否要隨之修改?多數國家(包括台灣)的《度量衡法》仍以太陽時為基礎
  • 太空探測器(如 Voyager、火星任務)的時間系統將如何銜接?NASA 與 ESA 尚未正式表態

外部延伸資源

網友熱門留言 (5)

#1 Hacker News 用戶 ▲ 168
BIPM 負責 UTC 標準,這份決議自 2027 年 5 月 20 日起停止新增或移除閏秒,至少持續到需要插入『閏小時』為止(屆時是否會真的這麼做也還不確定)。文件中列了幾個很好的理由⋯
#2 Hacker News 用戶 ▲ 92
終於!過去用 hack 補閏秒的歷史可以收進博物館了。電腦系統(特別是 UNIX 時間)一開始就該用 TAI、把閏秒追蹤丟給時區層才對。雖然還是比之前的混亂好,但真的太晚。
#3 Hacker News 用戶 ▲ 47
再見日晷,歡迎銫原子鐘。占星 App 開發者請記得在 Temporal 裡加上 UT1 漂移,特別是 2267 年前後,你的愛情與財運預測可能會大走鐘。
#4 Hacker News 用戶 ▲ 38
幾千年後,某個實體(不論是不是人類)會好奇:到底是哪些白癡做了這種讓他們生活更難的時間決定。Gods willing,Google 和 ChatGPT 那時都不在了,但他們會搜尋理由⋯
#5 Hacker News 用戶 ▲ 23
看起來是把當代問題卸給未來世代的『AI 無法解決一切』典型案例。