這是之前在工作上遇到的怪問題。
待過銀行的都知道他們很喜歡用IBM的東西，但IBM的產品最大的問題是「貴」，基本上什麼都要錢，而且伺服器的錢還是以使用量計費，所以近期比較有能力的銀行都急著想要擺脫IBM。
在這個背景下，當時負責的外匯系統要做優化，因為原本的系統前後端都是放在IBM的WAS上，伺服器主機也是用IBM的AS400，要改成放到X86系統的VM中，而且要能夠因應不同的負載量快速的平行擴充伺服器。
為了要徹底擺脫IBM，系統中原本用的IBM相關jar檔要全數換成open source的，另外為了要能平行擴充，原本一些synchronized的方法也要重新調整，雖然大家都說Java是跨平台的，但真的要搬還是遇到蠻多問題要調整。
好不容易都改好也花了一段時間測試完，上線後卻發生了一個怪問題，User在做交易時，發現有些日期在送出後會有減少一天的情形，而且這種問題只有某幾筆才發生，而大部分的交易都是正常的。因為這次調整只有針對jar檔和伺服器端的設定，原本程式的邏輯完全沒動，不太可能發生這種問題。雖然發生問題筆數不算太多，遇到還可以用人工修正，但使用者反映就是有問題，也只能儘快查了。
第一步，我先用測試環境重現了問題，在前端畫面上某顧客的生日顯示為1975-05-03，該顧客所有的交易最終到DB都變成是寫入1975-05-02，但另一名顧客同年生日1975-12-20卻是正常的。
因為系統前後端是以SOAP的webservice進行溝通，在原始碼是以物件而不是文字的方式傳遞，所以實際傳了什麼內容我也不大清楚，只能先把log印出來。發現這個欄位傳的內容不只日期，還連著後面的時間，如：1975-05-03 00.00.00，後端收到後再處理成只留日期，而有問題資料的傳過來會變成1975-05-02 23.00.00 少了一小時，然後處理完就變成1975-05-02 少一天了。看到少一小時，直覺想到可能是時區的問題。
為了驗證是不是時區的問題，我直接在畫面上的日期欄位限制使用UTC+8方式傳遞，這樣改了之後就沒問題了，雖然這個方法可以解決，但是外匯系統的日期欄位應該有上千個，也不能確定一些背景運作的日期會不會也有類似的問題，更何況這次的異動根本沒有動到程式，所以我不太想用這種改法，不過至少有個保底，如果最後搞不定，至少還可以請大家幫忙這樣改。
既然確定的時區的問題，那就回到這次有調整到的伺服器設定下手吧。原本前後端系統都是放在IBM 的 AS400 上並且application server使用的是WAS，而這次因為一些原因，只先把後端的伺服器搬到VMware上，application server使用red hat linux 的 JBoss。看了後端伺服器上的設定，都是UTC+8沒錯，所以一時之間也查不到根本的原因，現在只剩前端的伺服器沒有查，問了負責伺服器的SP，他們信誓旦旦的說前端伺服器根本沒改過任何的設定，都跟異動前一樣。
唉，人家都這麼說了，你怎麼辦？只能跪著拜託他，就讓我看一下，一下下就好… 前端伺服器的時區設定是JIST(Jung Yuan 中原標準時間)，設定一直以來都是這樣。IBM的技術文件如下圖，JIST是UTC+8沒錯。
感覺上前端也沒問題，那到底是什麼地方出錯了？這時候有個地方吸引了我的注意，就是上圖的「澳洲西部日光節約時間」，如果是日光節約的問題，也能解釋為什麼同一年，只有部分日期會少一小時。JIST的名稱又寫著「亞洲/香港」，所以是不是香港之前有過日光節約時間呢？
查了一下維基還真的有，最後一次是1979年，而且有問題的那些日期都是落在香港的夏令時間內，也就是說一直以來舊伺服器上的時區設定就是錯的，但為什麼之前都沒事，是因為原本前後端設定都是JIST，只要設定一致，處理前後就不會有少一小時的情況，也就不會發現問題，所以後來也把AS400上的時區改成GMT+8，和後端一致，這樣一來就都沒問題了。
在職場上做久了，會發現有很多問題跟技術面的關係都不大，能解決靠的都是靈光一閃和綠色乖乖。這種「解決問題」的能力跟學歷無關，跟經驗有一點相關但也不是絕對關係，也是遇過很多待了20年遇到問題兩手一攤的同事。這種能力很難量化，但想要變強一定要保持開放的心態，了解的東西愈廣對於解決問題愈有幫助。
Stay Hungry, Stay Foolish 共勉之。