除了 Y2K, 系統遇到閏年也是一個難關啊~~

　　今天是四年一次的閏年 Feb 29。

　　不約而同地，許多地方的不同系統都在這一個特別的日子開始作怪，這是就算乖乖也沒辦法保佑的災難。

　　我手上 CXBC 的通知平台系統，在這一天發出給客戶的交易通知，所有從西元年轉換成民國年的資料全部錯誤，顯示民國 97 年 2 月 28 日，讓客戶把今天和昨天的帳務全搞混在一起，客訴電話直逼服務人員腦門。

　　朋友在國 X 會負責的人資系統，也發現請假單開不出來，畢竟很多人會在今天請個假和 228 與週末湊個連續假期，不過幸運的是，請假作業是提前進行所以及早發現這個系統的毛病。但是另一個營運主系統則當得很慘，死機好幾個小時才搞清楚原來是閏年計算錯誤的問題。

　　【用民國年計算閏年是不行的！要用西元年，西元年！】

　　【這不是學校老師都會出的作業習題嗎？小小毛病鬧這麼大？】
　　( 這凸顯我這種非正統科班出身的程式員的訓練不足與悲哀 )

　　【你們這些廠商程式都不好好寫。】

　　透過 MSN ，我彷彿看到身為 MIS 的朋友難以置信地咆哮著...。

　　我遇到的問題呢，則是西元轉民國年，使用系統底層萬年曆運算，直接減去 1911 年所造成的，這種寫法的意思相當於，1911年前 ( 西元 97 年 ) 的今天的日期是幾月幾號。這樣的結果，找出的那一天當然不是閏年的二月 29 日。

　　聽到這樣做法的 MIS 朋友，簡直不可思議地直叫：見鬼了！

　　要在最短的時間內 ( 今天營業日之前 ) 緊急搶救這個問題，我採用最 dirty 的方法，直接字串取代的方式硬生生幹掉，不過這並不能完整地解決此問題，只是暫時性的規避。我發現，要完整的解決此問題還不是件容易的事呢！因為程式允許使用者傳入 DateTime Format String 來自訂日期格式，我是先知道使用者會使用 "yyy/MM/dd" 的格式然後在程式中硬生生地針對這種 Case 作 Replace，若真要完整解決，我還得自己撰寫完整的 FomatString Parser 才行，工程實在不小。

　　總之，先過今天再慢慢想完整的解法。

　　像這樣的 bug 四年出現一次，當初做再多測試也不太可能事前測出這樣的 bug，只能說要寫出個沒有 bug 的系統真是不太可能。

　　處理閏年的問題，就留個不會遺忘的慘痛經驗來記起教訓吧。