據《紐約時報》報道，紐約的停車收費表從 2020 年 1 月 1 日開始不支持信用卡付款，整個城市的一萬多個計費表已手動更新，僅通過現金或 ParkNYC 接受付款；波蘭公司 Novitus 生產的收銀機由于記錄時間故障而無法打印收據；視頻游戲 WWE 2K20 于 2020 年 1 月 1 日午夜停止工作；華為手表和部分設備丟掉了新年伊始兩三天的 TrueSleep 睡眠數據，需要更新并重啟……

[[312672]]

紐約市交通局表示，停車計時器的信用卡支付軟件設定在 1 月 1 日失效，導致了一起大規模故障（來源：The New York Times）

程序員 Jef Poskanzer 在推特上發文：似乎有相當數量的系統出現 #2020 錯誤。當年解決 Y2K 問題的方案把這個問題推遲了 20 年……20 年后的今天，當時的一些系統仍然還在使用，系統以為我們在 1920 年。”

Jef Poskanzer 的推文（來源：Twitter 截圖）

千禧年前后出生的青少年們或許很少有人知道“千年蟲”。

大約在 20 世紀 80 年代中期以前投用的系統上，囿于存儲空間有限，再加上人們普遍覺得系統更新會很快，所以程序員大多采用兩位數來表示年份，比如 06/15/98，而不是 06/15/1998。但是到了 2000 年，系統只知道是 01/01/00，不知道這是 1900 還是 2000。

千年蟲主要集中在配備較早的主機系統上，如在 IBM 4381，IBM AS/400 等機型上運行的應用程序，比如美國的 AT＆T 電訊公司，其內部就有超過 3.6 億行的應用程序需要檢測是否存在 Y2K 問題。另外，在自動化儀器儀表、電梯、警報系統、恒溫燈等嵌入式設備也容易存在千年蟲隱患。

視頻 Y2K 啟示錄（來源：YouTube）

計算機在上世紀六七十年代開始普及，到九十年代，人們開始意識到問題的嚴重性：不知道從 1999 年最后一天的 23:59 到 2000 年第一天的 00:00 的轉變意味著什么？在渲染和炒作下，大眾的驚恐程度不亞于“2012”。人們猜測，如果程序停止運行、崩潰或者發出錯誤指令，是否影響到銀行、電站、航線等等，存款會一夜清零、恐怖襲擊、飛機墜落、股市崩潰，世界陷入混亂？

當時甚至有媒體報道，有人把山洞當做避難所，存儲了很多食物、醫療包等必需品，還有一些人把銀行存款紛紛取出來或者是購買黃金。

1999 年 1 月 18 日，TIME 的封面（來源：Time）

為了避免 “災難” 發生，政府和企業動用大量資源查找和修復這個 bug。有報道顯示，當時克林頓政府和業內人士估計，用 “windowing” 的方式修補 80% 的計算機，預計耗資數千億美元。BBC 報道認為全球花在防備千年蟲上的費用在 3000 億到 5000 億美元之間。真實耗資目前無法考證。也有言論說千年蟲是個商業大騙局。

當時修復 bug 的方式有兩種：完全重寫代碼，或者采用 “windowing” 的方式快速修復。“windowing”就是把 00 到 20 之間的所有日期都當做 20XX 年而不是 19XX 年。很顯然，相比于把所有兩位數表示的年份都修改成四位數，后一種方式更省錢、更快而且更容易。

從 1970/01/01 開始，很多編程語言和系統都把日期時間以秒來處理，也叫 Unix time。因此，鑒于中點 1970 的重要性，編碼人員選擇 1920 到 2020 作為標準窗口。

Unix time 被廣泛用于各種行業操作系統，并被視為是一種標準。Unix 和 Windows 系統有環境變量來為系統設置 “轉折年”。“轉折年” 以后的任何一年屬于本世紀，“轉折年”以及 “轉折年” 之前的任意一年屬于上個世紀。但是一些產品，如 Microsoft Excel 95 使用的是 1920-2020 年的 windowing，在解決千年蟲問題之后，僅僅過 20 年就有可能再次出現日期錯誤。

[[312673]]

2020 年 “Y2K” 又回來了（來源：Popular Mechanics）

當時的專家認為，等到程序員投入大量的資金和時間去永久修復好這些 bug 之后，系統早就被更換了。所以，盡管 “windowing” 修復的程序智能使用二三十年，專家也覺得足夠了。

倫敦經濟學院 (London School of Economics) 的迪倫 · 穆爾文 (Dylan Mulvin) 表示：“windowing 是所有解決方案中最糟糕的一種，即便是在千年蟲問題期間。”

2020 年的到來，意味著我們已經進入到了 1920-2020 窗口期的末端。2019 年 11 月，由于被發現容易受到 Y2020“攻擊”，大數據公司 Splunk 向用戶推出了修復服務，它的用戶涵蓋了美國《財富》一百強公司中的 92 家。由于各家公司尚未披露相關細節，目前還不清楚 “Y2020” 將持續多久。

另外，在 2038 年我們將面臨另一個數據存儲問題。32 位的 Unix 和 Linux，能存儲的最大數字為 2 的 31 次方，即 2147483647。從 1997 年開始計算，2147483647 用來表示的秒數最多只能用到 2038 年 01 月 19 日 03 時 14 分 07 秒，在這個時間之后，系統會回到 - 2147483648，代表的時期是 1901 年 12 月 13 日 20 時 45 分 52 秒。

不同于千年蟲，2038 會影響的不僅僅是應用層，而是會影響到最底層的時間控制功能。不過幸運的是，如果能在 2038 年之前把所有 32 位系統淘汰并采用 64 位的話，我們將會巧妙地躲開 2038 問題。