日光時間惹的禍

大概是高中的時候，有人警告因為電腦計算年份的位數只有兩位的關係，所以在西元2000年的時候，許多電腦系統會大亂，可能造成不亞於世界末日的後果，也就是俗稱的「千禧蟲」。

西元2000年的時候，我還是個大學新鮮人，所以拯救世界這個重責大任，壓根不會落在我肩上；後來在IT界打滾的時候，碰上了民國100年，有些日期在記錄的時候是用6位數的文字欄位來放，這時候就要調整成7位數，好在我早就習慣用西元年來處理日期，所以也不用特別去處理這個問題，八位數的欄位要再過8000年才會不夠放，我想這個期間長到我可以不用去擔心。

不過最近遇到了一個跟日期處理有關的問題，是因為日光節約時間引起的，生活在早就不用日光時間的台灣，對這個陌生時制的處理，的確會比較沒感覺，更何況這是一個因法令修正而造成的問題。

最近做了一張報表的修改，需求是要把報表上的台灣時間，轉成PST時區（太平洋標準時間）的時間，增列在報表上，PST時區是美國及加拿大西岸在使用的，時間是GMT-8，台灣是GMT+8，所以這個需求的簡單處理方法，就是把時間減掉16個小時就好了。

但是很不幸地，PST是有採用日光節約時間的時區，所以在夏季，是要減掉15個小時的，雖然日光節約時間的起迄區間訂得很清楚，多寫幾行程式來判斷並不是難事，但我實在是有點懶得弄這個，就直接交給C#(.NET Framework)的library去做了。

不過就在上禮拜，我接到使用單位的通報，報表上10月31日的PST時間變成跟台灣差了16小時，當然我第一個反應就是日光節約時間結束了，於是查了一下資料，PST的日光節約時間是從每年4月的第一個星期日到10月的最後一個星期日，以今年來說，10月30日就結束了，那麼10月31日的資料，在換算時跟台灣時間會差16小時也是理所當然的啊。

但是事情並沒有這麼單純，我上了格林威致的網站去看PST的時間，發現日光節約並沒有結束啊，再更深入追查的結果，原來美國已經在2006年通過了能源節約法案，把日光節約時間的實施期間延長為每年3月的第二個星期日到11月的第一個星期日，也就是我的系統早了一個禮拜結束日光節約了，所以才會出錯。

C#的library在換算時間的時候，是會套用作業系統的時區資訊來計算，Server的作業系統版本是Windows Server 2003 SP2，發佈日期早於2006年，所以時區資訊是有可能出錯的，再深入追查下，在線上運作的兩台Server中，其中一台是能算出正確的結果，而另外一台不行，再去查兩台機器上的時區資訊，的確是有一些不同，如果使用者運氣不好被分配到有錯誤的的那一台Server，就會產出錯誤的報表。

在Microsoft的支援網站上，可以找到有關時區問題的修正方式，當然有可能是漏更新了修正這個問題的Patch或Hotfix，但是到底要用什麼方法才能正確處理這個問題，畢竟在運作中的主機上使用不確定的方式來修復是很危險的行為，更何況線上運作的主機也不允許在修復時重復開開關關，也就是除非我能找到一台狀況一樣的機器來實驗，不然要修復這個問題可能需要花費一點工夫了。

不過我想這個問題，還是交給機房的人員來處理吧，畢竟在管理主機這一方面，他們一定比我們這種搞軟體的要來得專業，而且要更新主機也算是他們的權責。