Excel 錯誤地將 1900 年視為閏年

背景

這篇來自微軟官方的技術文件探討了一個存在已久的軟體設計缺陷：Microsoft Excel 錯誤地將 1900 年視為閏年。雖然根據格里高利曆，1900 年並非閏年，但微軟明確表示為了維持與早期試算表軟體 Lotus 1-2-3 的相容性，決定保留這個錯誤，以避免在修正後造成現有大量數據與公式的混亂。

社群觀點

在 Hacker News 的討論中，社群對於這個「刻意保留的錯誤」展現了高度的理解與共鳴。多數開發者認為，這是一個典型的技術債轉化為產業標準的案例。留言指出，修正此問題的代價極高，因為這不僅涉及基準日期的變更，還會導致全球無數存檔中的日期數據產生一天的偏差。雖然有人提議可以透過版本號來區分不同的日期計算慣例，但隨即有反對意見認為，這會讓跨試算表的公式複製貼上變得極其容易出錯，反而增加使用者的負擔。事實上，Excel 為了相容 Mac 系統早已存在兩套日期系統，但這並未解決 1900 年的問題，反而增加了系統的複雜度。

除了對 Excel 的討論，社群也分享了許多令人啼笑皆非的硬體與軟體曆法錯誤。例如 Rockchip RK808 的即時時鐘（RTC）硬體設計錯誤，竟認為 11 月有 31 天，導致 Linux 核心至今仍需保留一段特殊的補丁代碼，專門在格里高利曆與這款晶片的「獨特曆法」之間進行轉換。另一個經典案例是微軟 Zune 播放器曾發生的集體當機事件，當時因為閏年判斷邏輯陷入死循環，導致全球所有 Zune 在同一天內全部癱瘓，直到 24 小時後日期跳轉才自動恢復正常。

討論中也延伸到了曆法設計的歷史趣味。有網友提到，現行月份名稱如九月（September，拉丁語意為第七）到十二月（December，拉丁語意為第十）之所以與實際序位不符，是因為古羅馬曆法最初是從三月開始計算，且冬季有約兩個月的時間完全不被計入曆法中，因為當時的農業社會認為冬季不具生產力，不需要精確的日期紀錄。這種從古至今對時間處理的「不完美」，反映了技術系統在面對現實世界複雜性與歷史遺產時的妥協。

延伸閱讀

• Joel Spolsky 的回憶錄：〈My First BillG Review〉一文詳細描述了早期 Excel 開發團隊與比爾蓋茲針對技術細節的討論，其中也涉及了對 Lotus 1-2-3 相容性的考量。
• 微軟官方說明：關於 Excel 中 1900 與 1904 兩套日期系統的詳細差異與切換方式。
• Linux 核心補丁紀錄：針對 Rockchip RK808 RTC 晶片 11 月 31 天錯誤的修復說明。