Excel日期中那個著名的bug

一個軟件中的bug可以持續多久？答案不一，大多數bug在軟件測試階段就已經被幹掉，又有許多死在Preview階段，抑或正式上線後不久被幹掉，有些則伴隨軟件終生，直到下一代產品發佈才壽終正寢，而Excel的日期計算上面有個很是著名的bug，從Excel誕生的時刻起，一直存在，無論Excel已經更新換代幾個版本，它依舊存在，而且會一直存在下去。

 

要重現這個bug很是簡單，打開Excel(任意版本)，選中一個單元格，格式化單元格：

選擇日期格式，肯定。

而後在此單元格中輸入60，bug出現了：

60變成了1900年2月29日，事實上，1900年的2月並無29日，1900年並非閏年，雖然它能被4整除，但因爲它的個位十位都是0，必需要被400整除才能算閏年。

 

這個bug今天依然大行其道，我爲何提起它？我今天真的中招了，咱們在作Excel數據導入的時候，常常要將導入內容轉爲程序特定類型，好比轉爲程序的的DateTime類型，而咱們從Excel中讀取的內容則不固定，一個欄位命名應該是日期，但讀進來是個整數，稍微搜索一下便知道，這個整數是從1900年1月1日算起的天數，1900年1月1日是1,1900年1月2日是2，這簡單了，遇到這種狀況，我只須要寫出這樣的代碼便可：

 

DateTime value = new Date(1900, 1, 1) + TimeSpan.FromDays(valueFromExcel-1);

 

我嘗試了幾個日期，1900年1月1日，1900年1月31日，1900年2月1日，都沒問題，但若是日期是2018年某天就不對了，我發覺按照個人作法，會致使計算結果多出一天出來，好比明明應該是2018年8月1日的，卻恰恰變成了2018年8月2日。

 

這種不一致的緣由你們都知道了，問題就出在那個1900年的2月29日上，當日期數值是60時，Excel的理解是1900年2月29日，而咱們的程序並不認爲這天是存在的，所以就理解爲1900年3月1日，因此從60開始，老是比Excel裏展現的多出一天。

 

解決方法很簡單，多加個判斷就好了，代碼我就不寫了。

 

使人驚訝的是，這麼簡單而顯著的bug爲何會出現，而且還持續了這麼長時間，還將一直持續下去？

 

《軟件隨想錄》中提到了這個典故，做者Joel Spolsky曾爲微軟工做，開發了Excel的Basic腳本語言，比爾·蓋茨還專門給他開了審查會，這個逼格真是夠高的了，你們一塊兒經過這本書的摘錄來了解下這個典故。

看完這個相信你們對這個bug都有充分認識了，並不怎麼嚴重，徹底是最先的程序員爲了方便而留下的bug，但後繼修正又面臨太多遺留問題，只好一直「兼容」着這個bug，經過這個故事咱們也真的瞭解到了——比爾·蓋茨真的很是瞭解技術，雖然你能夠找出一些例子來講明「運營一家偉大的軟件公司並不須要懂技術」，但瞭解技術自己難道對成功的運營一家偉大的軟件公司沒有幫助嗎？