「國際地球轉動服務組織」宣佈2015年7月1日要增加1秒，也就是「閏秒」，要增加這一秒，解法有很多種，在此紀錄幾種解法。
閏秒要增加1秒的解法種類
下述內容摘錄自此篇：Linux 創始人：面對閏秒，我們只需喝杯小酒
- 閏秒是什麽？
- 科學上有兩種時間計量系統：基於地球自轉的天文測量而得出的“世界時”和以原子振蕩周期確定的“原子時”。「世界時”由於地球自轉的不穩定（由地球物質分布不均勻和其它星球的攝動力等引起的）會帶來時間的差異，“原子時”（一種較恒定的時制，由原子鐘得出）則是相對恒定不變的。這兩種時間尺度速率上的差異，一般來說一至二年會差大約1秒時間。」
- 1971年國際計量大會通過決議：使用“協調世界時”來計量時間。當“協調世界時”和“世界時”之差超過0.9秒時，國際地球自轉服務組織（IERS）就負責對“協調世界時”撥快或撥慢1秒，這就是閏秒。
下述內容整理自此篇：只因「閏秒」這 1 秒的解決方案，AWS 工程師可能花上數百小時
閏秒發生原因：
- 在探討閏秒對電腦系統帶來的影響之前，先來看看什麼是閏秒。在「時間」的度量衡上，分為以原子鐘為標準計時的「協調世界時」（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 次閏秒，而且都是正閏秒，2015 年 7 月即將增加的這 1 秒，則是第 26 次。
- 當要增加正閏秒時，會加在第 2 天的 00:00:00 前，也就是把 23:59:59 的下 1 秒記成 23:59:60，然後才是第 2 天的 00:00:00。如果是減去負閏秒時，則將 23:59:58 的下一秒減去，直接進入第 2 天的 00:00:00。
- 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系列的交換器。