這一秒,困擾了程式設計師 50 年——閏秒終於要被取消了!

整理 | 鄭麗媛

2012 年 6 月 30 日晚,美國著名新聞社交網站 Reddit 突然癱瘓了約 40 分鐘,同一時間包括開源社區 Mozilla、領英等許多網站也突然崩潰,巧得一度令很多人摸不到頭腦。

好在很快,事件的罪魁禍首就被發現了:閏秒。換句話來說,就是那天晚上出現了一個奇怪的時間——23:59:60。就因為多了的這一秒,讓沒有準備好的計算機程序產生異常並崩潰。

而如今,這個令無數科技企業「頭疼」了許多年的閏秒,終於要沒了:近日,在法國巴黎閉幕的第 27 屆國際計量大會上,與會代表通過一項決議,決定最遲在 2035 年取消閏秒。

備註:文末有周五抽獎福利~

備註:文末有周五抽獎福利~

備註:文末有周五抽獎福利~

閏秒從何而來?

閏秒是什麼?簡單來說,我們可以把它理解成兩套時間標準之間的誤差:基於地球自轉的世界時(UT)和基於原子振盪週期的國際原子時(TAI)。

二者之間,一直與地球自轉時間相匹配的世界時首先在 1927 年確立,但隨著科技發展,人們發現地球每天的自轉速度也不一樣,它會受潮汐、地殼運動等因素影響而越變越慢。

也就是說,在世界時的標準下,一天並不是固定的 24 小時,總會有幾毫秒誤差。當然,我們的日常生活可能並不會受此影響,但對太空探測、衛星導航等對時間精確度要求極高的領域而言,世界時顯然是不夠用了。

在這一精度需求下,在 1967 年,國際度量衡大會決定,用基於銫原子穩定週期性的電磁波,重新定義「秒」的時長,即國際原子時。但也由於原子時非常穩定,而世界時會隨著地球自轉會越來越慢,兩者之間的差距會逐漸變大,於是在 1972 年,結合了這兩個時間標準的「協調世界時(Coordinated Universal Time 簡稱 UTC )」出現了。

「協調世界時」以國際原子時秒長為基礎,同時規定,當世界時與原子時之間時刻累計相差超過 0.9 秒時,就在「協調世界時」上加上或減去 1 秒,以儘量接近世界時——這 1 秒,就是閏秒。

自從 1972 年有了「閏秒」這個概念後,這 50 年來全球已經加了 27 次閏秒,而最近的一次調整是在 2017 年 1 月 1 日 7 時 59 分 59 秒(時鐘顯示 07:59:60)出現。

計算機中令人「頭疼」的閏秒問題

計算機中令人「頭疼」的閏秒問題

本來呢,這多一秒少一秒的,對我們來說,基本是沒什麼影響的,但對於伺服器而言卻是一整個「天差地別」。

在計算機運行中,既定的子任務排程過程中會觀察相對應的時間,而時間會以毫秒甚至更短的時間進行精度切分,一旦時間發生一些跳變,就會導致伺服器宕機、系統崩潰或時間對應不一致等帶來的一系列問題。

因為多了一個閏秒,很多工會因為時間條件不匹配而啟動失敗,程序就會不停嘗試、一直循環,直到伺服器過載。而且,閏秒和閏年還不一樣,沒有規律可循,程式設計師也無法一開始就提前寫進系統,從而導致了開頭所說的 Reddit、領英等網站崩潰,部分 Linux 伺服器 CPU 利用率飆升等等。

對此,不同科技企業之間的解決方式也不盡相同。部分網站可能習慣依賴公共時間伺服器,選擇直接停 1 秒或者跳 1 秒;而Google和 Meta 這類大型科技企業則採用「閏秒彌補」(Leap Smear)的方式,將閏秒分解為大量微小的部分,每次更新都增加幾毫秒,最終增加至 1 秒以保證伺服器正常運行,但這也並不是萬全之策。

呼籲廢除閏秒

呼籲廢除閏秒

在這種情況下,也難怪許多科技企業對「閏秒」的存在積怨已久——今年 7 月,Google、微軟、Meta 和亞馬遜四家科技巨頭聯合呼籲廢除閏秒,理由是每次出現閏秒,都會對網路造成顯著影響。

關於閏秒的廢除,Meta 工程師 Oleg Obleukhov 與科學家 Ahmad Byagowi 還專門發表了一篇文章,稱:

  • 「每當引入閏秒時,我們都會遇到問題。」

  • 「閏秒是一種弊大於利的冒險做法,我們認為現在是時候引入新技術來取代它了。」

  • 「就算沒有閏秒,現在的時間狀態也至少足以支撐下一個千年。」

對此,美國國家標準與技術研究院(NIST)與國際計量局(BIPM)表示贊成,在 11 月 18 日第 27 屆國際計量大會上,科學家和各國政府代表們也投票決定到 2035 年取消閏秒。

據 Nature 報道,來自加拿大,美國和法國的代表都投了贊成票,呼籲閏秒能在 2035 年取消,但投了反對票的俄羅斯代表則希望能將日期推遲到 2040 年或更晚,以預留時間調整其衛星導航系統 GLONASS 中有關閏秒的技術問題。

根據最新決議,目前閏秒還將繼續存在,最晚將從 2035 年開始,允許原子時和世界時之間的誤差累計超過 1 秒。不過美國國家標準與技術研究所物理學家朱達·萊文也補充道:「這種誤差允許累積到多長時間,我們還沒有決定。」

因此,各方代表將舉行談判,在 2035 年之前確定一個累積時長以及如何處理這一時長的方案——但在這之前,程式設計師們該對閏秒做的應對措施還是要做,直至這一決議真正生效。

參考連結:

  • https://www.nature.com/articles/d41586-022-03783-5

  • https://engineering.fb.com/2022/07/25/production-engineering/its-time-to-leave-the-leap-second-in-the-past/

相關文章

C、C++ 將退休,Rust 欲上位?

C、C++ 將退休,Rust 欲上位?

整理 | 蘇宓 Rust 這把火在微軟Azure CTO Mark Russinovich的助力下,似乎越燒越旺。而每當波及程式語言時,紛爭...