導讀 | 第27屆國際計量大會宣布最遲不晚于2035年取消引入閏秒，這一消息引起轟動。上一次閏秒產生，對Reddit、Mozilla、FourSquare等都產生了一定的問題，其中Reddit宕機時間超過1個半小時！本欄目特邀騰訊后臺開發(fā)工程師陶松橋，帶你是深入了解閏秒的來源及其影響，并介紹各類系統(tǒng)常見的閏秒處理方法，其中會分享TencentOS Server 操作系統(tǒng)的解決方案。

(資料圖片僅供參考)

閏秒從何而來世界上有幾種計量時間的方式：世界時（UT1）：是一種天文計量的方式，天文學家通過觀測地球的自轉，并將自轉一周的時間（一天）等分為86400份，每份為一秒，受潮汐等因素的影響，地球自轉一周的時間并不是恒定的，這也是造成閏秒現(xiàn)象的直接原因。原子時（TAI）：由于上面描述的世界時并不穩(wěn)定，物理學家用更為穩(wěn)定的量子計量的方式來統(tǒng)計時間，1967年，國際計量大會用銫133（Cs133）原子基態(tài)的兩個超精細能級之間的躍遷所對應輻射的9192631770個周期所持續(xù)的時間定義為1秒，這個是目前最精確的時間計量方式，其誤差為1400000年一秒，基本可忽略不計。協(xié)調世界時（UTC）：又稱世界標準時間或世界協(xié)調時間，UTC以TAI為基礎，又要兼顧UT1，當UTC，和UT1之間的偏差接近1秒時，國際地球自轉和參考系服務（IERS）會提前6個月公布下一次閏秒的時間。我們將世界絕大多數(shù)地方時區(qū)的基本時間稱為協(xié)調世界時，即 UTC。它源自分布在世界一些國家的大量原子時鐘。地球的自轉并不是非常恒定的，有時會有一些變化，平均自轉速度會緩慢下降。這就是為什么會在 UTC 時標中插入所謂閏秒，它們可將 UTC 時間進程調整到真實地球自轉時間。為什么會多出這一秒呢？它的存在是因為決定晝夜更替的地球繞軸自轉會在很長的一段時間內慢下來，主要是由月亮-太陽引力造成。另外，地球也受其內部（地核、地幔）和外部（氣候、海洋）構成影響。目前，時間主要由分屬幾個國家的 250臺原子時鐘測量，這些原子鐘是通過測量原子的能量轉換水平工作。使用這些時鐘計算 UTC，同時因為這個時間測量原理周期性地與地球不同步，因此必須使用閏秒進行校正。另外，我們必須考慮到現(xiàn)在的一天比 1820年的一天要長 2 毫秒。不出所料，地球自轉慢慢就與 UTC 不同步了。國際地球自轉服務局IERS 測量的是真實地球自轉，并決定何時插入閏秒。插入閏秒一般總是在某個月的最后一天進行，首選六月或十二月的 UTC 午夜時間。過去每次添加閏秒都是在六月或十二月進行。是否添加閏秒的聲明，會由 IERS 在其Bulletin C 中發(fā)布。目前，在可能添加閏秒日期前半年會公布 Bulletin C 。因為閏秒是在全世界同時插入，插入閏秒的本地（民用）時間取決于本地時間與 UTC 之間的偏差，例如：2015年7月1日發(fā)生閏秒時，在時區(qū) UTC+8h（北京時間）中，閏秒會在時鐘顯示午夜后 8 小時的時候插入。閏秒時計算北京時間的標準方法為：

2015-07-01 07.59.572015-07-01 07.59.582015-07-01 07.59.592015-07-01 07.59.60 <-- 閏秒2015-07-01 08.00.002015-07-01 08.00.012015-07-01 08.00.02

如果系統(tǒng)時鐘采用國際原子時（TAI），并使用正確的時區(qū)，那么就會列出 23:59:60。但因為在 Unix 的 UTC 使用中不存在 23:59:60，Linux內核會采用倒回一秒的方法在0:00 UTC 后第一次時鐘更新時插入閏秒。在本地時間計時中，根據(jù)不同的時區(qū)偏差，比如 UTC+8h，在TencentOS Server系統(tǒng)中，您會觀察到以下現(xiàn)象：

2015-07-01  07:59:58.0002015-07-01  07:59:58.5002015-07-01  07:59:59.0002015-07-01  07:59:59.5002015-07-01  08:00:00.000 <-- 插入閏秒2015-07-01  07:59:59.0002015-07-01  07:59:59.5002015-07-01  08:00:00.0002015-07-01  08:00:00.500

IERS 確定閏秒后，一些時間傳播服務還會發(fā)布閏秒通知。這包括德國長波發(fā)射機 DCF77 和衛(wèi)星巡航系統(tǒng) GPS 示例。因此，可解碼從那些系統(tǒng)獲取信號的接收器也可以解碼閏秒通知。如果在所應用協(xié)議中包含閏秒信息（例如接收器傳送的時間字符串），則從那些接收器讀取時間的應用程序也可以確定閏秒通知。請注意，時間代碼接收器只能將閏秒通知轉發(fā)到應用程序，同時正確計時。正確處理閏秒是應用程序和（/或）操作系統(tǒng)的任務。從1972年到2020年，平均每21個月就插入一次閏秒。然而，間隔是非常不規(guī)則的，而且明顯在增加。在1999年1月1日至2004年12月31日的六年中沒有閏秒，但在1972-1979年的八年中有九個閏秒。自1972年協(xié)調世界時正式使用至今，全球已經實施了27次正閏秒調整，最近一次的閏秒調整是格林尼治時間2016年12月31日。從協(xié)調世界時正式使用以來，地球自轉一直處于不斷減慢的趨勢，因此迄今為止的閏秒都是正閏秒。但相關科研發(fā)現(xiàn)，自2020年年中以來，地球自轉速率呈現(xiàn)加快趨勢，這意味著未來也可能會出現(xiàn)負閏秒。目前TAI與UTC的秒差為37：

#  Value of TAI-UTC in second valid beetween the initial value until#  the epoch given on the next line. The last line reads that NO#  leap second was introduced since the corresponding date #  Updated through IERS Bulletin 64 issued in July 2022#  ##  File expires on 28 June 2023###    MJD        Date        TAI-UTC (s)#           day month year#    ---    --------------   ------   #    41317.0    1  1 1972       10    41499.0    1  7 1972       11    41683.0    1  1 1973       12    42048.0    1  1 1974       13    42413.0    1  1 1975       14    42778.0    1  1 1976       15    43144.0    1  1 1977       16    43509.0    1  1 1978       17    43874.0    1  1 1979       18    44239.0    1  1 1980       19    44786.0    1  7 1981       20    45151.0    1  7 1982       21    45516.0    1  7 1983       22    46247.0    1  7 1985       23    47161.0    1  1 1988       24    47892.0    1  1 1990       25    48257.0    1  1 1991       26    48804.0    1  7 1992       27    49169.0    1  7 1993       28    49534.0    1  7 1994       29    50083.0    1  1 1996       30    50630.0    1  7 1997       31    51179.0    1  1 1999       32    53736.0    1  1 2006       33    54832.0    1  1 2009       34    56109.0    1  7 2012       35    57204.0    1  7 2015       36    57754.0    1  1 2017       37

閏秒處理方案1）運行NTP的系統(tǒng)系統(tǒng)如果使用 NTP（網絡時間協(xié)議）守護進程（ntpd）將其本地計時與 NTP 服務器同步，則都應自動進行閏秒調整。進行閏秒調整的前一天，NTP 服務器應通知其客戶端第二天的 23:59:59 UTC 會發(fā)生發(fā)生閏秒，Linux 內核應通過兩次顯示第 60秒或徹底刪除它，以便添加或者刪除額外一秒。因此，在閏秒調整期間，運行 NTP 的系統(tǒng)應有如下計時顯示：

2015-06-30 23:59:59 UTC2015-06-30 23:59:59 UTC2015-06-30 00:00:00 UTC

發(fā)生閏秒時，內核會在系統(tǒng) log 中寫入信息：

Jul  1 07:59:59 TENCENT64 kernel: [579201.951291] Clock: inserting leap second 23:59:60 UTC

使用ntpdate命令方式，與ntp服務器進行時間同步的系統(tǒng)，將不會通過ntp服務器接收到閏秒通知，而是在系統(tǒng)管理員指定的時刻與ntp服務器進行時間同步。例如，系統(tǒng)管理員設定每小時的第52分與ntp服務器進行時間同步，那么在7月1日08:00 CST到09:52之間，系統(tǒng)時間與ntp服務器時間會相差1秒（快1秒）。2）運行PTP的系統(tǒng)PTP（精確時間協(xié)議）中交換的時間戳通常采用不包含閏秒的TAI（國際原子時）；但 ptp4l 和 phc2sys 將設置內核標簽，插入閏秒以便系統(tǒng)時鐘繼續(xù)以 UTC 運行。然后該內核就可以正常插入閏秒。3）未運行NTP或者PTP的系統(tǒng)默認情況下，不使用 NTP 或者 PTP 同步其計時的 Linux 系統(tǒng)不會修正閏秒，且這些系統(tǒng)報告的時間與修正閏秒后的 UTC 時間有一秒鐘的差別。閏秒發(fā)生后應手動重置時鐘。您還可以將 tzdata 更新至最新版本，將/usr/share/zoneinfo/right 目錄層級中的正確文件復制到/etc/localtime，并將時鐘重置到正確的本地時間，以便將這些系統(tǒng)配置可正確報告時間。/usr/share/zoneinfo/right 中的文件包含自該世紀開始，從 1970年 1 月 1 日00:00:00 UTC 發(fā)生的所有閏秒修正的本地時間信息。/usr/share/zoneinfo 中的其他時區(qū)文件未添加閏秒修正。從1972年至今，共添加了 27次閏秒。例如：如果某個系統(tǒng)位于中國時區(qū)，您可以將其重新配置為通過運行以下命令報告閏秒修正時間，

cp /usr/share/zoneinfo/right/Asia/Shanghai /etc/localtime

例如在TS2系統(tǒng)中，tzdata包的版本為tzdata-2015a-1.tl2.noarch，執(zhí)行完上述拷貝后，則會在閏秒發(fā)生時間2015年7月1日8點自動插入閏秒。4）windows系統(tǒng)早期的Windows版本(Win10版本以前)時間服務并不表示 Leap 指標的值，當 Windows 時間服務接收到的數(shù)據(jù)包，包括閏秒。因此，閏秒發(fā)生后，正在運行 Windows 時間服務的 NTP 客戶端會比實際時間快一秒。這種時間差異在下次同步時解決。從 Windows 10 Redstone 5 和 Windows Server 2019 起，微軟的操作系統(tǒng)能以更精確、UTC 兼容和可追蹤的方式處理閏秒。不過從2017年至今，沒有發(fā)生過閏秒了。歷史影響對于日常生活而言，正常的上班、下班、工作、學習，生命中偏差的這一秒無關痛癢。然而閏秒對于精確要求時間的行業(yè)如航空、航天、軍工等，會產生較大影響。對于服務器清一色linux系統(tǒng)的互聯(lián)網行業(yè)而言，閏秒可能會造成機器cpu突然增高，機器宕機、對應的服務掛掉。隨著linux的普遍使用，閏秒的影響也被越來越多的被關注。歷史上，因為linux內核的一些問題，閏秒對系統(tǒng)造成多次影響。比如CPU利用率高會給生產環(huán)境帶了不少挑戰(zhàn)。2012年實施閏秒時，國外不少知名網站出現(xiàn)了臨時服務中斷。當2015年閏秒再度來臨時，工程師們修復了部分2012年出現(xiàn)的問題，但卻東窗事發(fā)——發(fā)現(xiàn)了新的問題。后續(xù)亦是如此。閏秒讓互聯(lián)網企業(yè)如鯁在喉。1） linux-2.6.22以前內核版本的閏秒死鎖07年的commit：http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=746976a301ac9c9aa10d7d42454f8d6cdad8ff2b;hp=872aad45d6174570dd2e1defc3efee50f2cfcc72每次時鐘中斷觸發(fā)時會調用 tick_do_update_jiffies64 更新 jiffies 的值。因此在更新前對 xtime_lock 加了寫鎖。閏秒產生時，開發(fā)者需要修正jiffies 的值。在 tick_do_update_jiffies64 里面最終會調用到 second_overflow 這個函數(shù)，以處理潤秒。在函數(shù) second_overflow 里面，處理潤秒的增加和減少前都調用了一個 clock_was_set 函數(shù)。該函數(shù)內部，請求了 xtime_lock 的讀鎖。此時，與先前的寫鎖發(fā)生死鎖。該patch在linux內核版本2.6.22中引入，所以只有2.6.22內核之前的系統(tǒng)可會出現(xiàn)該問題，也就是影響sles10和centos5.5系統(tǒng)。在sles10和centos5.5中，clock_was_set()因不支持高精度時鐘而被定義為空，所以不造成影響。2）linux-2.6.25到2.6.27內核版本的系統(tǒng)死鎖Bug 479765 - Leap second message can hang the kernel 描述了leap second會對系統(tǒng)產生影響的原因：當一個leap second被插入或刪除時，內核會打印一條相關信息：[69596.647516] Clock: inserting leap second 23:59:60 UTC而該信息的打印會因xtime_lock而造成系統(tǒng)死鎖。下面是2.6.26內核下該問題出現(xiàn)時的棧信息(this is with Fedora 8 andkernel kernel-2.6.26.6-49.fc8.x86_64)：

#0 ktime_get_ts (ts=0xffffffff8158bb30) at include/asm/processor.h:691#1 0xffffffff8104c09a in ktime_get () at kernel/hrtimer.c:59#2 0xffffffff8102a39a in hrtick_start_fair (rq=0xffff810009013880, p=) at kernel/sched.c:1064#3 0xffffffff8102decc in enqueue_task_fair (rq=0xffff810009013880, p=0xffff81003fb02d40, wakeup=1) at kernel/sched_fair.c:863#4 0xffffffff81029a08 in enqueue_task (rq=0xffffffff8158bb30, p=0xffff81003b8ac418, wakeup=-994836480) at kernel/sched.c:1550#5 0xffffffff81029a39 in activate_task (rq=0xffff810009013880, p=0xffff81003b8ac418, wakeup=20045) at kernel/sched.c:1614#6 0xffffffff8102be38 in try_to_wake_up (p=0xffff81003fb02d40, state=, sync=0) at kernel/sched.c:2173#7 0xffffffff8102be9c in default_wake_function (curr=, mode=998949912, sync=20045, key=0x4c4b40000) at kernel/sched.c:4366#8 0xffffffff810492ed in autoremove_wake_function (wait=0xffffffff8158bb30, mode=998949912, sync=20045, key=0x4c4b40000) at kernel/wait.c:132#9 0xffffffff810296a2 in __wake_up_common (q=0xffffffff813d3180, mode=1, nr_exclusive=1, sync=0, key=0x0) at kernel/sched.c:4387#10 0xffffffff8102b97b in __wake_up (q=0xffffffff813d3180, mode=1, nr_exclusive=1, key=0x0) at kernel/sched.c:4406#11 0xffffffff8103692f in wake_up_klogd () at kernel/printk.c:1005#12 0xffffffff81036abb in release_console_sem () at kernel/printk.c:1051#13 0xffffffff81036fd1 in vprintk (fmt=, args=) at kernel/printk.c:789#14 0xffffffff81037081 in printk ( fmt=0xffffffff8158bb30 "yj$\201????\2008\001\t") at kernel/printk.c:613#15 0xffffffff8104ec16 in ntp_leap_second (timer=) at kernel/time/ntp.c:143#16 0xffffffff8104b7a6 in run_hrtimer_pending (cpu_base=0xffff81000900f740) at kernel/hrtimer.c:1204#17 0xffffffff8104b86a in run_hrtimer_softirq (h=) at kernel/hrtimer.c:1355#18 0xffffffff8103b31f in __do_softirq () at kernel/softirq.c:234#19 0xffffffff8100d52c in call_softirq () at include/asm/current_64.h:10#20 0xffffffff8100ed5e in do_softirq () at arch/x86/kernel/irq_64.c:262#21 0xffffffff8103b280 in irq_exit () at kernel/softirq.c:310#22 0xffffffff8101b0fe in smp_apic_timer_interrupt (regs=) at arch/x86/kernel/apic_64.c:514#23 0xffffffff8100cf52 in apic_timer_interrupt () at include/asm/current_64.h:10#24 0xffff81003b9d5a90 in ?? ()#25 0x0000000000000000 in ?? ()

從上面的棧信息我們可以發(fā)現(xiàn)：該問題的出現(xiàn)原因是當對leap second進行操作（插入或刪除）之前，已經獲取了xtime_lock鎖；而之后在調用printk()打印日志信息時，printk()中會嘗試喚醒klogd內核線程，在喚醒過程中會調用到公平調度類的相關函數(shù)，其中會調用ktime_get()獲取時間信息，其中會再次嘗試獲取xtime_lock鎖，從而造成死鎖。該現(xiàn)象部分因為hrtick_start_fair()函數(shù)的引入。是由commit 8f4d37ec (high-res preemption tick)引發(fā)，這大概在2.6.25版本引入。但是在2.6.25之前的內核，不會發(fā)生這個死鎖。2.6.28版本引入了commit b845b517。printk()中的wake_up_klogd()不會直接wake_up klogd()，也就不會觸發(fā)后續(xù)的xtime_lock，最終避免了死鎖的發(fā)生。所以，該原因引起的系統(tǒng)死鎖只可能發(fā)生在linux內核2.6.25到2.6.27版本下。Sles11使用2.6.27內核，屬于比較危險的部分內核。但是Novell聲稱已經引入了commit b845b517b5e3706a3729f6ea83b88ab85f0725b0，因而不存在該問題，而且?guī)讉€小時的實驗后系統(tǒng)仍然正常。此問題影響的版本還有 RHEL4:kernel-2.6.9.89.EL之前的版本，RHEL5.3：kernel-2.6.18-128.37.1.el5之前的版本。現(xiàn)網centos5.5使用的內核版本是2.6.18-194.el5，其不受影響。3）linux-3.4內核版本的系統(tǒng)活鎖08年的commit中為了解決之前遇到的leap second問題而將對leap second的處理從second_overflow()中獨立出來，使用定時器來完成此工作。但是12年的commit認為該patch存在如下可能的livelock場景：

CPU 0 CPU 1do_adjtimex()spin_lock_irq(&ntp_lock);process_adjtimex_modes(); timer_interrupt()process_adj_status(); do_timer()ntp_start_leap_timer(); write_lock(&xtime_lock);hrtimer_start();  update_wall_time();hrtimer_reprogram(); ntp_tick_length()tick_program_event() spin_lock(&ntp_lock);clockevents_program_event()ktime_get()seq = req_seqbegin(xtime_lock);

問題在于，引入ntp_lock的commit（http://patches.linaro.org/5122/）是在3.4內核版本，且在3.4內核得到了修復。所以此問題對3.4以前和以后的內核無影響。08年的commit：https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=7dffa3c673fbcf835cd7be80bb4aec8ad3f5116812年的commit：https://lkml.org/lkml/2012/3/15/6164）linux-2.6.32內核插入閏秒可能出現(xiàn)高CPU消耗2012年的閏秒插入當時導致了一些互聯(lián)網公司的服務器高cpu消耗，其問題根源在以下網址得到了闡述：https://lkml.org/lkml/2012/7/1/203leap-a-day.c為一個小測試程序，編譯后加-s參數(shù)運行，可每10秒插入或者刪除一個閏秒，用戶可自行下載編譯測試。2015年7月1日的閏秒將會出現(xiàn)以下現(xiàn)象：

Setting time to Wed Jul 1 07:59:50 2015Scheduling leap second for Wed Jul 1 08:00:00 2015Wed Jul 1 07:59:57 2015 + 98 us (3883) TIME_INSWed Jul 1 07:59:57 2015 + 500248 us (3883) TIME_INSWed Jul 1 07:59:58 2015 + 366 us (3883) TIME_INSWed Jul 1 07:59:58 2015 + 500483 us (3883) TIME_INSWed Jul 1 07:59:59 2015 + 598 us (3883) TIME_INSWed Jul 1 07:59:59 2015 + 500740 us (3883) TIME_INSWed Jul 1 07:59:59 2015 + 910 us (3883) TIME_OOPWed Jul 1 07:59:59 2015 + 501046 us (3883) TIME_OOPWed Jul 1 08:00:00 2015 + 1214 us (3884) TIME_WAITWed Jul 1 08:00:00 2015 + 501359 us (3884) TIME_WAITWed Jul 1 08:00:01 2015 + 1481 us (3884) TIME_WAITWed Jul 1 08:00:01 2015 + 501599 us (3884) TIME_WAITWed Jul 1 08:00:02 2015 + 1650 us (3884) TIME_WAIT

我們測試后發(fā)現(xiàn)，在TS1.2發(fā)行版下，可出現(xiàn)“ERROR: hrtimer early expiration failure observed”提示。

/* Test for known hrtimer failure */void test_hrtimer_failure(void){ struct timespec now, target; clock_gettime(CLOCK_REALTIME, &now); target = timespec_add(now, NSEC_PER_SEC/2);clock_nanosleep(CLOCK_REALTIME, TIMER_ABSTIME, &target, NULL); clock_gettime(CLOCK_REALTIME, &now); if (!in_order(target, now)){ printf("ERROR: hrtimer early expiration failure observed.\n"); }

分析代碼可以發(fā)現(xiàn)：使用clock_nanosleep(CLOCK_REALTIME, TIMER_ABSTIME, &target, NULL);這種定時器方式，在插入閏秒后，該定時器本應該0.5秒到期，卻立刻到期。本質原因是內核中記錄時間的數(shù)據(jù)結構中并沒有表達閏秒的地方,因此在增加閏秒時需要特別調整這些數(shù)據(jù)結構。而很多定時器并不直接使用“絕對”時鐘而使用相對的時間間隔，這樣，在定時器代碼中就應該對閏秒做額外的檢查。但問題是這樣的檢查之前被刪掉。對于許多應用來說，定時器的一次提前觸發(fā)并不是什么問題。但有些定時器則不然，他們會反復啟動自己，這樣的后果就是它們反復地被快速喚醒，于是系統(tǒng)負載就出現(xiàn)了觀察到的尖峰現(xiàn)象。閏秒的插入沒有調用clock_was_set()，來提醒hrtimer子系統(tǒng)改變。定時器在插入閏秒后，其基準比系統(tǒng)時間快一秒，因此會提前一秒到期。在觀察到cpu高消耗后，解決方法很簡單，執(zhí)行下述命令即可：

date -s "`date`"

其原理就是date再設置一下當前系統(tǒng)時間，clock_settime(CLOCK_REALTIME,&ts)會調用clock_was_set()。為了應對ntpd同步可能出現(xiàn)的該問題，我們在2015年特意編寫了一個解決程序，該程序經過編譯后可以添加到crontab任務：

58 7 1 7 * /data/solve_hrtimer_failure.o > /data/solve_hrtimer_failure.log 2>&1

在7月1日7點58分開始，每隔100ms檢測閏秒是否插入了，當插入閏秒后，該程序調用clock_settime函數(shù)，進而修復了該問題。取消閏秒1）為何取消閏秒對閏秒最為敏感的莫過于計算機相關領域。由于閏秒的出現(xiàn)沒有固定規(guī)律，對應的時間調整無法從一開始就寫在計算機程序里。在萬物互聯(lián)時代，很多領域都依托計算機網絡傳輸信息，實施閏秒也會影響航空、通信、金融及其他需要精準對時的領域。今年7月Meta公司兩名工程師發(fā)文稱：“閏秒是一種弊大于利的冒險做法，我們認為現(xiàn)在是時候引入新技術來取代它了?！边@一表態(tài)引來各大公司稱道。2）取消閏秒的后續(xù)可能負責協(xié)調世界時的國際計量局（BIPM）表示，科學家和政府代表18日在法國舉行的一次會議上投票決定到2035年取消閏秒。BIPM時間部門負責人帕特里齊亞·塔維拉表示，這項“歷史性決定”將允許“秒數(shù)連續(xù)流動，而不會出現(xiàn)目前由不規(guī)則閏秒造成的不連續(xù)性。閏秒是目前把世界時和國際原子時聯(lián)系起來的手段。由于世界時是基于地球自轉確定的，又稱天文時或太陽時。沒有閏秒意味著人們使用的時間與地球自轉、太陽位置不關聯(lián)，時間和天文學呈現(xiàn)割裂狀態(tài)。第27屆國際計量大會決議要求多機構協(xié)商，提出一個可以將協(xié)調世界時持續(xù)至少百年的新方案并制定實施計劃，納入下一屆大會的決議草案中。根據(jù)決議，閏秒將暫時繼續(xù)正常添加。但到2035年，世界時和國際原子時之間的差異將被允許增長到大于一秒的值。也許解決這個問題的可能方法是讓世界時和國際原子時之間的差異增加到一分鐘，但專家估計調整時長在50到100年之間。而有提議指出，無需在時鐘上增加閏分鐘，而是將某一天的最后一分鐘變?yōu)樾枰獌煞昼?；也有人建議停止校正，同時公布世界時和國際原子時之間不斷增長的時刻差。

騰訊工程師技術干貨直達：

1、算法工程師深度解構ChatGPT技術

2、10分鐘！從架構視角讀懂K8s

3、探秘微信業(yè)務優(yōu)化：DDD從入門到實踐

4、祖?zhèn)鞔a重構：從25萬行到5萬行的血淚史

關鍵詞：