除了 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 的系統真是不太可能。

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

熱門文章