據「國際地球轉動服務組織」發布的世界時間，7 月 1 日將增加 1 秒，即「閏秒」。短短的 1 秒，眨一眨眼就過去了：但原來此 1 秒對電腦程式、各種系統都為嚴重的問題，工程師、系統管理員等更要花上數以百計的小時及數不盡的額外功夫去應付此特殊情況。

 

何謂閏秒？

探討閏秒對電腦系統的影響前，各位讀者可先了解何謂閏秒。「時間」的度量衡上，分為有以原子鐘為標準計時的「協調世界時」(Coordinated Universal Time，UTC) 與根據地球自轉、公轉，再以地球極軸運動修正的「世界時」(Universal Time 1，UT1)：前者為世界各國依循使用的標準時間，以英國格林威治的時間為基準，香港時間較英國格林威治快 8 小時，亦即 UTC+8。

但由於地球自轉速度會因地質分布及其他星球引力的影響，導致轉速非規律一致，時有快慢，故 UTC 與 UT1 並非同步。而為協調上述兩種時間標準，避免太陽升至正中央、時鐘卻標示為午夜 12 點的問題出現：國際計量大會於 1972 年就決定於原子鐘與世界鐘出現超過 0.9 秒的時差之際就加上或減去 1 秒，令 UTC 可以配合到 UT1，而此 1 秒就稱為「閏秒」(Leap Second)。

而自 1972 年閏秒誕生至今，已出現過 25 次閏秒，而且 25 次均同樣為正閏秒，即將於 7 月增加的 1 秒就因第 26 次。而正閏秒時的方法為於 23:59:59 的下 1 秒記錄成 23:59:60，再下一秒就為另一天的 00:00:00；負閏秒時則為將 23:59:58 的下一秒 (23:59:59) 減去，直接進入下一天的 00:00:00。

 

AWS 解決方案：將閏秒分散出去

對一般人而言，應對閏秒的方法不外乎就為將時鐘、手錶調快或調慢 1 秒；但對於電腦系統而言，由其是需要精準對時的 GPS、通訊設備、金融系統等，就可謂海嘯級的問題。更由於閏秒的出現並毋特定規律，所有是乎所有系統的設計上都未有針對閏秒而設的調整方案。

回顧上一次閏秒出現的 2012 年 6 月 30 日至 7 月 1 日當日，由於各網站底層並無應變此 1 秒，令多間如 Reddit、Mozilla、RedHat、LinkedIn 等網站都紛紛當機，可見閏秒對系統的破壞力非同小可。

而近年雲端的出現與其受歡迎程度令閏秒的「破壞力」不斷上升，作為眾多網站營運人員選用的 Amazon Web Services 就為其中一間需要嚴肅處理閏秒的科企之一：而 AWS 就將「不增加閏秒，但仍保持時間與 UTC 一致」。

更確切一點而言，AWS 並不打算為系統於 23:59:59 後加入 23:59:60：而是將這 1 秒平均攤在閏秒出現前後的 24 個小時，讓每秒的秒數稍微增長一點點，最後補滿 1 秒。

 

此手法的好處為系統時鐘毋需特別為閏秒設計「23:59:60」，仍舊以 60 秒為 1 分鐘的單位，而且除 23:59:60 此閏秒記時與 UTC 不同步以外，其他每秒依舊與 UTC 同步。儘管 UTC 加入閏秒前，AWS 系統時間將較 UTC 快；而加入閏秒後 AWS 又會較 UTC 慢，但總括而言，此差距均不大於 0.5 秒，並不會對系統構成影響。

而除上述如 AWS 「將閏秒分散」的處理手法外，其他方法還有如 Linux Kernels 般將 23:59:59 重複一次、如 Windows time servers 忽略閏秒，在閏秒增加後再讓系統時間與 UTC 同步等多種方式。但與金錢流動攸關的的股票交易市場則對閏秒較為敏感，甚至避開於閏秒出現之時進行交易：如芝加哥商品交易所 (CME) 與洲際交易所就計劃將 6 月 30 日夜間電子開市的時間延後，以避開閏秒。

(本文由 TechNews 授權轉載)