閏秒要增加1秒的解法種類

「國際地球轉動服務組織」宣佈2015年7月1日要增加1秒,也就是「閏秒」,要增加這一秒,解法有很多種,在此紀錄幾種解法。

閏秒要增加1秒的解法種類

下述內容摘錄自此篇:Linux 創始人:面對閏秒,我們只需喝杯小酒

  • 閏秒是什麽?
    • 科學上有兩種時間計量系統:基於地球自轉的天文測量而得出的“世界時”和以原子振蕩周期確定的“原子時”。「世界時”由於地球自轉的不穩定(由地球物質分布不均勻和其它星球的攝動力等引起的)會帶來時間的差異,“原子時”(一種較恒定的時制,由原子鐘得出)則是相對恒定不變的。這兩種時間尺度速率上的差異,一般來說一至二年會差大約1秒時間。」
    • 1971年國際計量大會通過決議:使用“協調世界時”來計量時間。當“協調世界時”和“世界時”之差超過0.9秒時,國際地球自轉服務組織(IERS)就負責對“協調世界時”撥快或撥慢1秒,這就是閏秒。

下述內容整理自此篇:只因「閏秒」這 1 秒的解決方案,AWS 工程師可能花上數百小時

閏秒發生原因:

  1. 在探討閏秒對電腦系統帶來的影響之前,先來看看什麼是閏秒。在「時間」的度量衡上,分為以原子鐘為標準計時的「協調世界時」(Coordinated Universal Time, UTC),以及依據地球自轉、公轉運動,再以地球極軸運動修正的「世界時」(Universal Time 1, UT1)。前者就是世界各國依循使用的標準時間,以英國格林威治的時間為基準,台灣時間比英國格林威治快上8個小時,即 UTC+8。
  2. 至於這兩個時間的度量衡有什麼差別呢?事實上,地球自轉的速度並非規律一致,而會因地質分布或其他星球引力的影響,導致時快時慢,但長遠來講會越來越慢,因此以規律的原子鐘為基準記時的 UTC,會與以天文現象記時的 UT1 不同步
  3. 為了協調兩個時間,不讓太陽上升到正中央、時鐘卻走到了午夜 12 點,這種時刻與自然節律不一致的狀況發生,1972 年,國際計量大會決定在原子時與世界時差距超過 0.9 秒時,就加、減 1 秒,讓 UTC 配合 UT1,而那 1 秒,也就稱做為「閏秒」(Leap Second)。
  4. 自 1972 年以來,已經出現過 25 次閏秒,而且都是正閏秒,2015 年 7 月即將增加的這 1 秒,則是第 26 次。
  5. 當要增加正閏秒時,會加在第 2 天的 00:00:00 前,也就是把 23:59:59 的下 1 秒記成 23:59:60,然後才是第 2 天的 00:00:00。如果是減去負閏秒時,則將 23:59:58 的下一秒減去,直接進入第 2 天的 00:00:00。
  6. 2015 年這一次的增加正閏秒,台灣時間發生在 7 月 1 日 07:59:59 的下一秒,即 07:59:60,再來才是 08:00:00。

對應「閏秒」的各種解法

Amazon (AWS) 解法:

  • 「不增加閏秒,但仍保持時間與 UTC 一致」
  • AWS 並不打算讓系統在 23:59:59 之後,加入 23:59:60 這 1 秒鐘的閏秒;它採用的做法是,將這 1 秒平均攤在閏秒出現前後的 24 個小時,讓每秒的秒數稍微增長一點點,最後補滿 1 秒。
  • 更仔細來說,一天有86400秒,閏秒即是 86400/86400,從 6 月 30 日 12:00:01 PM(中午)開始,AWS 系統的時鐘每秒都會增加 1/86400 秒,每秒長度變成 1+1/86400秒,過了 24 小時至 7 月 1 日 12:00:00 PM 時,就剛好補滿 1 秒。
  • 解法詳見:Look Before You Leap – The Coming Leap Second and AWS

Linux Kernels 解法:

  • 把 23:59:59 重複一次

Windows time servers 解法:

  • 忽略閏秒,在閏秒增加後,再讓系統時間與 UTC 同步即可

註:我採用 Windows time servers 的解法. XD

下述摘錄自此篇:小心AP突然重開機!明早8點閏秒調整,VMware、甲骨文、思科皆呼籲MIS要盯緊

  • 如VMware在官方產品說明網頁上表示,配置了NTP用戶端程式的系統會有潛在風險,當天這類系統會收到有閏秒標是的NTP封包,如果企業的系統未針對閏秒進行調整,排程機制可能因為出現相同的時間戳記(Timestamp)而鎖死,導致系統必須重開機。或是Java環境也可能因為無法對閏秒進行例外處理,造成CPU使用率達到100%,進而讓服務中斷。部分產品若為啟用slew模式,也可能無法處理60秒的時間戳記。
  • 甲骨文官網上則提醒,雖然Java API已每一秒定義為介於0至61的數字,以防範閏秒的發生,但是有些應用程式僅定義1分鐘為60秒,一旦遇到閏秒調整可能會導致應用系統出錯。因此,甲骨文建議,系統管理者在閏秒發生的時間內更加關注系統的狀況。另外,舊版MySQL (5.1.31以前的版本),也可能因系統回傳了閏秒,而導致呼叫Now()函數時傳回59分61秒的錯誤時間值,程式若未能處理這樣的例外也可能導致出錯。而思科也列出了可能會可能受到閏秒影響的多款產品,如Nexus1000v及Nexus 5000系列的交換器。

關於「Tsung」

對新奇的事物都很有興趣, 喜歡簡單的東西, 過簡單的生活.
分類: News,標籤: , 。這篇內容的永久連結

發表迴響

這個網站採用 Akismet 服務減少垃圾留言。進一步瞭解 Akismet 如何處理網站訪客的留言資料