最近開發碰到一個關於DateTime轉換的業務，幾個系統的區域語言(CultureInfo)設置都不一致，位置是控制面板-時鐘、語言區域-更改日期、時間和數字格式。
線上服務器 en-GB
開發環境 zh-CN
測試服務器 en-US
代碼主要涉及兩個方法DateTime.ToString()和DateTime.Parse(string)，如果各種轉換都在同一個application上跑基本是不會有問題，比如：
var d = DateTime.Parse("2013-03-11 00:56:20");
var dStr = d.ToString();
var dNew = DateTime.Parse(dStr);這樣的代碼能完全正常的，現在的場景會涉及到一個Console exe(簡稱A)和IIS上一個Web Service(簡稱B)，麻煩就出現了。
A的CultureInfo默認是讀取系統配置，在A中執行
var d = DateTime.Parse("2013-03-11 00:56:20");
var dStr = d.ToString();三個環境的dStr都不一致
en-GB 11/03/2013 00:56:20
zh-CN 2013/3/11 00:56:20
en-US 11/3/2013 0:56:20 AM
接下去將dStr傳入B，在B中執行
var dNew = DateTime.Parse(dStr);
這時候會發現DateTime.Parse無法識別dStr，這是因爲IIS本身有自己默認的CultureInfo設置CultureInfo.InvariantCulture，這個默認配置並不區分en-GB還哦zh-CN等，所以幾乎無法識別與CultureInfo有關的日期格式。
解決方案：
1. 設置IIS的CultureInfo爲對應值，或者給DateTime.Parse指定對應的CultureInfo，這個方法弊端很大，因爲Web Service本身是提供服務給客戶端的，如果限制了一個CultureInfo，對來自各個區域的客戶端是不公平的，例如設置成zh-CN，我想英國的客戶端會瘋掉；
2. IIS保持CultureInfo.InvariantCulture默認配置，那麼只好設置客戶端的CultureInfo，直接也指定成CultureInfo.InvariantCulture，大家都公平就最好了；
總之就是讓大家的CultureInfo都一致，不要隨便在DateTime.Parse指定CultureInfo我覺得是最好的實踐，除非你無法控制dStr的來源格式。