「閏秒」會對 IT 行業造成多大影響？有什麼好的解決方法？

11-28

相關新聞：2015年全球將迎第26次「閏秒」比往年漫長1秒

用 NTP, 這種事情由 ntpd 和內核來操心，你不用管。
另外閏秒都可能造成時間突變影響業務了，跳一分鐘能活？

簡單來說，閏秒的信息在由IERS(International Earth Rotation and Reference Systems Service)決定並公布過後，會存儲在NIST的一個專門列表(NIST Time Scale Data Archive)裡面，ntpd 在啟動之後會訪問 NIST 的時間伺服器獲取這個 leap-seconds.list 文件，然後它就知道什麼時候有怎樣的閏秒了。如果是直接接在時間源（比如GPS啊原子鐘啊之類的）上面，好像GPS是會下發閏秒信息的，原子鐘和PPS這種不清楚。當（和時間伺服器校準的）系統時間走到這個地方的時候就會由 ntpd 控制內核做出閏秒的動作來。

在不同操作系統內核中閏秒的實現有所不同，貌似 Windows 就是按表面定義的多走一個 60 秒，這個以前在哪裡看到過但記不清了等打臉。

NTP中閏秒的實現是通過操作內核讓系統時間「凍結」一秒，也就是說 59 秒會持續現實中 2s 的長度。NTP中有一個標誌位用於標記當前是否處在閏秒狀態，在閏秒發生前的一段時間（通過NIST公告的閏秒文件、GPS傳來的閏秒通告、上級伺服器下發的閏秒通告等）這個標誌位會被置為01.

在POSIX系統中，第一個按正常速度流逝的 59 秒過後，因為閏秒標誌位的存在（所以系統知道這個時候應該+1s），系統時間會停止前進並跳回到第 59 秒的開頭重來一遍，此時如果對系統時間進行訪問會被記錄為 60 秒（更正：內網看到有人測試過了，用date反覆訪問的話會列印兩次59秒，不過這個可能對應於前面說的流逝量沒有超過一秒的情況，具體實現細節的不太清楚），隨後正常跳到 00 秒，閏秒標誌位重置為00，閏秒完成。當然在實際實現上會更複雜，比如為了保證系統中前後操作的有序性，每對系統時間做一次訪問就會增加一個非常微小的量，但加起來不會超過一秒。

這樣的實現不會造成定時任務等依賴系統時間的操作出錯，因為定時任務是在 00:00:00 秒執行的，閏秒完成之前系統時間不會變成下一天。取時間戳更省事，這貨和閏秒根本沒關係。

上面是科普版的簡單描述，詳細文檔在：The NTP Timescale and Leap Seconds
至於實現細節請翻閱代碼...新版本的 ntp 裡面閏秒相關的代碼大致在 ntpd/ntp_leapsec.h, ntpd/ntp_leapsec.c 裡面，4.2.7之前的版本可能沒有這兩個文件，不太清楚在什麼地方_(:зゝ∠)_

話說好久沒碰過 ntp 的代碼了爬上去翻了半天最後跑去看測試裡面的包含關係然後用 find 大法才找到...

更新：擴展閱讀 The Unix leap second mess

/**** 一秒之後更新 ****/

今天早上起來後在伺服器上找到了這樣的日誌

messages:Jun 30 19:59:59 tsukasa kernel: [98535.952158] Clock: inserting leap second 23:59:60 UTC messages:Jun 30 20:00:00 tsukasa ntpd[1838]: 0.0.0.0 061b 0b leap_event

然而其實我連夜搞了個小東西用來每隔10ms記錄一次系統時間，打算抓出來實際閏秒時候系統時間的變化的..........................但是 cronjob 沒執行起來...............................

這個故事告訴我們，凌晨寫代碼會忘記做測試，還是好好睡覺吧&<(=╥﹏╥=)&>

另外對於那些時間同步精度要求非常高的應用，可以用「滑動」的方法來度過閏秒，也就是把之前/之後一段時間的每一秒加長或者縮短一個很小的量，來避免閏秒時候的跳躍，比如阿里雲就用了這種方法：阿里雲產品博客

目前已知 openntpd 支持這種方式，ntp 前一陣有看到討論，但不清楚具體支持的版本信息（貌似是最新的幾個開發版裡面才有，沒細看不確定）

首先說明結論，旨在消除部分不負責任的報道給讀者帶來的恐慌：
2015 年 6 月 30 日午夜的閏秒，對科技界、對大家的日常生活可能帶來的影響微乎其微。

關於閏秒（Leap Second）存在的原因和大部分軟體系統對閏秒的處理方式，在互聯網上不難查到。為了方便非技術背景的人了解這個問題的全貌，我把分散在各種信息源的幾點重要信息簡單匯總一下。

為什麼要有閏秒
由於潮汐等地質作用，地球的自轉速度並非恆定。每隔一段時間，目前世界範圍內通用的協調世界時（UTC）會與依據地球圍繞太陽運動計算的平太陽日（Mean Solar Time）和世界時（UT1）出現很小的偏差。因此需要對 UTC 增加或減少一秒來消除這個偏差。

多長時間有一次閏秒
會對地球自轉速度產生影響的因素包括潮汐、地殼運動、冰川融化、地震等自然現象，這些作用的疊加使得地球自轉速度的變化並不均勻，有時變快有時變慢，因此每次閏秒的間隔不固定且無法預測。
每次地球自轉速度的偏差積累到一定程度時，國際地球自轉和參考系服務（IERS）會基於實際觀測，提前六個月公布下一次閏秒的時間，以保證 UTC 和 UT1 的偏差不超過 0.9 秒。閏秒的修正通常在該年度的 6 月 30 日或 12 月 31 日午夜進行。
最近的三次閏秒分別發生在 2005 年 12 月 31 日、2008 年 12 月 31 日和 2012 年 6 月 30 日。
從 1988 年這一做法被確立至今，一共發生過 25 次閏秒。2015 年 6 月 30 日會是第 26 次閏秒。

閏秒對普通人有什麼影響
簡單的說就是幾乎沒有任何影響。
閏秒的設置與時區無關，全世界都在同一時刻發生。因此對處於東八區的中國而言，下次閏秒的實際時間是 7 月 1 日早上 7 點 59 分 59 秒。
大部分民用設備本身就很容易會產生秒級的時間誤差，閏秒的作用完全可以忽略不計。可聯網的電子設備如手機電腦基本都能夠與互聯網同步時間，閏秒發生後系統時間會自動同步。
對於時間精度要求較高的設備和應用，如 GPS、通訊設備等，閏秒並不是一個突然出現的新概念，過去 30 年裡已經發生過 20 多次。這些設備在設計的時候就充分考慮了閏秒，可以正確處理。但是閏秒畢竟是一個發生頻率不高且不規律的事件，針對它的測試可能會不周全，所以不排除少數設備會因為軟體 bug 受到影響。

2012 年閏秒那天部分網站宕機、航班延誤是怎麼回事
軟體和互聯網行業日新月異，每年都有大量代碼和程序被創作出來。而最近十年只有三次閏秒，肯定會有很多開發者不熟悉這個概念，在編寫一些對通訊依賴較多的程序時沒有意識到閏秒可能帶來的影響，埋下隱患。2012 年一些著名網站和公司受到影響，大多是一些由局部 bug 引發的系統級問題。不過當年出現問題並引起關注的程序，基本可以認為都已經修復了相關 bug。
IERS 在 1 月 5 日公布 2015 年 6 月的閏秒後，軟體公司和開源社區有接近 6 個月的時間再次檢查各種可能受到影響的程序。樂觀的看今年六月底應該不會出現什麼大的混亂；悲觀的話，也可以說人都會犯錯誤，所以也一定會有網站和服務受到影響。在我看來，也許稍顯刻薄，到 2015 年還在處理閏秒上犯低級錯誤的大型生產級程序，是會被科技界嘲笑的。

專業人士怎麼看待閏秒
實際上閏秒確實會為計算機和軟體系統帶來一些問題，主要原因是它的不可預測性——誰都不知道在未來六個月里會不會有一次新的閏秒。另一方面閏秒的相關知識在世界範圍的開發者群體中普及率較低，不難預見很多程序員的時間將會浪費在「犯錯誤-&>發現錯誤-&>學習閏秒相關知識-&>（罵粗口）-&>修改錯誤」這樣的過程中。
有些國際機構曾經提出取消閏秒的議案並在國際大會上進行表決，但這些議案目前都處於駁回或延期決定的狀態。學界至今提出的新方案也都還存在各種問題，不能完美替代閏秒。業界的解決方法則多從務實需求出發，比如 GPS 系統的時間以原子時（TAI）而非 UTC 為參照。這部分討論需要的術語和專業知識過多，就不再展開了。

結論：

閏秒每過幾年就會有一次，雖然沒有規律不能預測，但會提前至少六個月公布。有些新編寫的考慮不全的程序也許會出錯，但是絕大部分專業系統在設計時就考慮了閏秒，而且早已經歷過一兩次閏秒的實際檢驗。因此普通人的生活不會受到什麼影響。

寫這個回答，就是希望大家不要被某些聳人聽聞的報道牽著鼻子走。了解一點關於閏秒的知識，也不失為一個有趣的談資。

POSIX時間，是各種不同平台都採用的時間表示方法。它是用從EPOCH(也就是1970年1月1日0:00:00.00)開始的總秒數，不計算閏秒，來表示一個時刻。
為什麼不計算閏秒呢？看看下面這個閏秒的列表，閏秒是沒有規律的！

因為沒有規律，你甚至沒辦法提前把幾年之後的閏秒寫到系統庫里。要讓庫可以長久的使用，只有不去管它。
這會帶來什麼問題？閏秒的23:59:60秒，沒法用POSIX時間表示。

不過，對大多數系統來說，差一秒就差一秒了，沒什麼影響。最多什麼時候有空，和網上的原子鐘對對錶，也就完了。
GPS，用的也是相對時間，不用管它。當然，如果你的手持設備是用GPS提供的時間對錶的話，它有可能差一秒。但是，這又能怎麼樣呢？
就算系統需要時間戳判斷先後順序的，如果不需要7x24工作的話，可以暫時不管它，到停止營業的時候再調整。

能影響到的，也就是在7x24x365運行的大集群系統里，不同的機器需要統一的精確時間。這樣的場合，還真不多。
如果系統不大，也許可以在那幾秒之內，讓交易排隊，暫時停止處理。幾秒鐘影響可能也不大。
對更大的系統，谷歌的方案就不錯。

真的沒什麼……

至於你說的，閏分，好像不太可行。我能想像，比如火車飛機之類的，差一秒，沒問題，本來精度也沒那麼高；差一分鐘，就可能要出事了……

作為一個程序員，很難想像這麼簡單的規則會對IT行業造成什麼破壞啊。你只要在小學的時候普及這個知識，長大了他們寫程序都知道什麼是閏秒，就再也不會出事了——就跟2月有時候有29號一樣。

不過，美國乾脆呼籲取消閏秒，因為閏秒會對導航以及通訊系統造成破壞，並且會干擾依賴時間的貨幣貿易。

我呼籲取消閏年因為閏年的存在導致幾千萬人四年才能過一次生日

今天早上到公司後，發現數據中心大部分的系統全部CPU負荷過高，造成應用系統無法正常訪問，最後發現是linux系統通過ntp同步時間後，無法正常處理7:59:60這麼一個格式，應用需要調用本地時間時無法處理，造成系統負荷逐漸升高。
系統重啟後恢復正常……真真是災難的一天

6月30晚接到的通知：

由於地球自轉的不均勻性和長期變慢性（主要由潮汐摩擦引起的），會使世界時（民用時）和原子時之間相差超過到0.9秒時，為了讓「原子時」與「世界時」協調一致，今年7月1日全球將增加一秒。具體為在北京時間2015年7月1日7時59分59秒(即格林尼治時間2015年6月30日23時59分59秒）進行閏秒調整。
由於這個原因，如linux機器（主要是中間件或者資料庫）開啟了時間同步服務時，由於時間會增加一秒，可能會導致linux機器內核崩潰。為避免該問題，需要在今天晚上關閉時間同步服務。具體操作如下：
1、在linux機器上通過root用戶登錄，然後使用以下命令檢查是否開啟時間同步服務；
命令行中輸入：[root@localhost ~]# /etc/init.d/ntpd status
如果返回
ntpd (pid 7797 7794) 正在運行...
代表已經開啟時間同步服務。
2、如果開始時間同步服務的，請在今天晚上關閉時間同步服務，具體的方法為：
1）**********
2）**********
3、請在明天（2015年7月1日）早上8：00後以後再開啟時間同步服務。
1）**********
2）**********

註：若本來即未開啟時間同步服務，本次閏秒事件不會對系統造成影響。

從另一個方面考慮，以後校驗秒數時要考慮60也是一個合法的值。

唉，苦逼的程序員。

如果你的取唯一的時間id，那麼就可能回獲取本來認為是唯一，但是不是唯一的東西。
這樣會可能會出現不可預期的問題，很多系統都存在這樣的問題。

發現大家只關注it行業，其實實時性要求強的實在工業上，智能電網250微秒一次採樣，如果錯位，很可能保護跳閘，你們搞it的伺服器都沒電了，也就沒啥影響了。

沒有經歷都是吹！
沒有經歷都是吹！
沒有經歷都是吹！
重要的事情講三遍。
大牛都說了理論上閏年都是小Case。
實際上，閏秒前中心要求廠商支持提出相關解決方案，廠商說系統支持閏秒，為以防萬一，建議關閉ntp，採用系統本地時鐘源。千台伺服器啊，做要做死人啊。那怎麼辦，還有個方案，提前斷開上級時鐘源。恩，斷了，啥筆的是系統內設24小時應用設置，更啥筆的是部分版本(新版本)內核bug，系統cpu爆，宕機。至於影響，生產系統多台不確定範圍x86 linux系統宕機，影響很大，場面很難看。
這個故事教育我們，
不要輕易相信大牛
不要輕易相信廠商
不要輕易相信Linux

舉個例子，你是做交易系統的，然後有一些關鍵性的後台任務要在每天凌晨跑，但是那一天多了一秒，這出現的問題就會很大了

北京時間2017年1月1日7時59分59秒後，全球同步多出1秒。

這事兒，對日常生活影響不大。

若處理不當，也可能引發危機。2012年閏秒發生時，包括LinkedIn在內不少國外知名網站都曾遇到故障。

為了協助用戶更好的應對2017年元旦的閏秒，2016年的12月19日阿里雲在官方網站發布公告，介紹閏秒可能影響的群體，以及應對方案。

阿里雲提供的ECS雲伺服器中帶有自己的NTP服務。所以，2017年1月1日，阿里云為客戶提供了兩個選擇

為用戶默默解決閏秒問題。這一服務，免費提供。
有些用戶技術實力強希望親手操作閏秒修改，也是可以的。只是，需要提前確認所使用的操作系統版本已不受閏秒影響，就可以自行更改NTP配置。

北京時間1月1日07:59:60，阿里雲採用ECS雲伺服器NTP系統24小時「消化」閏秒的方案，實現了與標準UTC時間的完美重合。

所有雲上用戶，在毫無感知的情況下，靜靜度過了這多出來的1秒。

這一次，阿里雲技術團隊提前2個月準備了2017元旦閏秒解決方案。

與很多公司採取在在7點59分59秒增加一秒鐘的做法不同，阿里雲ECS雲伺服器採用的方案是，將多出來的這一秒分平均分配到24小時（即86400秒）中，在閏秒時刻前12小時開始，閏秒後12小時結束。

理論上，能直接添加閏秒那也是極好的。

現實情況是大量的操作系統和應用軟體處理不了閏秒，會導致各種異常。

最常見的情況是，如果伺服器操作系統是Linux，在一些老的內核版本中存在BUG無法處理閏秒。導致收到閏秒通告消息可能會down機、插入閏秒可能會down機、列印閏秒日誌也能引發down機。

即便不down機，在應用層，應用程序也可能無法處理這多出來的1s導致應用core掉。甚至可能影響到那些對時間敏感、事務性較強的應用，比如DB。

目前，國際大公司通用的解決方案是將這一秒分成許多份，再平均分配到一整天中。

日本有一家股票交易所將這一秒平均分成 7200 份，分攤到兩個小時里，在分攤結束時間恢復同步時，剛好趕上開市。

Google則是在閏秒時刻前的24小時開始逐步調慢時間，理論上在閏秒時刻前，和標準UTC時間最大誤差趨近於1秒。

阿里雲採用的方案是在閏秒時刻前12小時才開始調慢。所以，最大誤差為0.5秒。

你知道嗎，AWS美東地區不少用戶都down了，發現是和AWS直連的某個網際網路提供商down了。雖然不是AWA本身的責任，但是閏秒的影響還是有點。

據我了解，不少公司都在標準時間0點之前開始conference call來應對可能出現的問題。

公司ntp伺服器全部暫停同步躲過一劫。

在閏秒到來之前，我們停掉了所有伺服器的ntp服務，包括aix和linux系統。閏秒過後再次開啟服務。所以這是ntp操心的事情。只是在關閉期間或許有可能伺服器之間的時間不同步，但是非常影響有限。隨意對於通信系統而言，只要操作沒問題，影響幾乎為零。

get

依然是單身狗
依然是程序猿

還是原來的配方
然並卵

我想知道當閏秒發生時，假設，恰好我的Java代碼使用了new java.util.Date()，這個時候得到的返回是什麼？以GMT+8時區為例，2015年7月應該會出現7:59:60這個時間，如果恰好在這個時間Java代碼執行了new java.util.Date()，能得到7:59:60這個時間嗎？
不知道閏秒對我們的代碼還有沒有其他方面的影響？

不要搞得像千年蟲一樣。