日期時間是開發過程中最嘗使用的資料類型之一,但是很多開發人員在使用過程中忽視了時間日期的一些特性。現在的應用越來越講究“國際化”和“本地化”,它們的重要特征之一就是一些資料類型的格式或換算,日期時間是其中之一(其餘還有貨币,數字等等)。在進一步讨論開發中的日期時間問題之前,我們需要先理清有關時間的一些基礎概念:
國際标準時間:為了讓時間問題比較容易得到解決,國際上定義了國際标準時間(Universal Coordinated Time或Coordinated Universal Time)這一概念,它要求全球範圍内都以零經度線上的時間作為國際上統一采用的标準時間。因為零經度線通過英國格林威治天文台,是以國際标準時間也稱為格林威治時間(GMT,Greenwich Mean Time)。此外,它又被稱為UTC(Universal Time Code)。很多朋友會被那麼多名詞和縮寫所迷惑,其實它們都表示同一個概念。其中,UTC可能是國際标準時間最常用的稱呼,在這片文章中我也将使用UTC時間來代指國際标準時間。
時區:理論上地球任意兩個不同的經度的地點就有不同的“當地時間”,是以在地球東西方向移動絲毫就改變了目前位置的時間。但是追求這樣的“精确”在大多數時候與場合都會顯得非常麻煩,而且沒有任何意義。為了解決這個問題,國際上又提出了時區(time zone)這個概念。按照時差的劃分方法,從西經7.5度到東經7.5度劃為“中區”,又稱之為“零時區”。然後依次向東西兩邊每15度劃分一個時區。例如,從東經7.5度到東經22.5度為東一區、西經22.5度到西經37.5度為西二區。整個地球被劃分為24個時區,每個時區使用該區的中央經線的“當地時間”作為這個時區的時間。
地方時:地方時(Local Time)其實有兩種概念:
第一種是指每個時區所用的時間,與中區的時間相比,向東時區的時間依次變晚,向西則依次變早。我們在表示某個時區的時間時,可以使用相對于UTC時間的表示法,例如東二區所用的時間為UTC +2,表示它比UTC時間要晚2小時。同理,西一區使用的時間為UTC -1。這種表示方法可以在很多場合看到。
由于地球被劃分為不同的國家和地區,是以我們站在不同“土地”的角度上來看,“地方時”又有了另一個概念。例如中國,幅員遼闊,橫跨64個經度,從東五區到東九區整整5個時區,但是幾乎整個中國都使用北京所在的東八區的時間,正所謂“中原標準時間”,這也是中國在國際上所用的時間。但是并非每個國家都使用同一個時間,例如美國就使用了東部時間和西部時間,甚至還有冬令時和夏令時(例如在一些外企有跨國團隊協作,在某一時刻往往就會有Email來通知,提醒從某月某日開始将采用哪種時間,因為從那時開始,美國人相對于中國的工作時間就改變了)。正因為有個這樣的變化,其實搞清楚這種“地方時”遠比第一種來的複雜。
時差:顧名思意,時差(time difference)指的是兩個時間的時間差。理論上這是一個非常精确的值,但是事實上由于提出了時區的概念,時差在進行計算時往往就是整數個小時。
對于時間日期來說,最重要的可能就是“時差”問題,主流程式設計語言中表示日期時間對象都對于這個問題有着足夠的支援,不過許多開發人員都會忽視這一點。這就是這片文章中最主要會談論的問題。雖然大部分的應用可能都不涉及到“全球化”,但是我們還是有充分的理由來搞清楚時間方面的問題:
為了将應用推向其他市場作準備。有一條“準則”叫做“Think Global, Do Local”,這要求我們在設計和開發應用程式時都思考一下這方面的問題。例如我們一直所說的“使用utf-8作為網頁的編碼”就是這一準則的一個實踐。在處理日期時間方面,我們經常會使用的一個實踐就是“使用UTC時間作為存儲”。目前流行的開發語言中的日期時間一般都會包含“時區”的概念,但是在例如Sql Server 2005等存儲系統對于時區沒有良好的支援。是以在将時間存入Sql Server 2005時,強烈建議先将日期時間轉為UTC時間。
将應用程式的執行效果獨立于部署環境。我們在開發時使用的很多功能會帶上系統設定的時區,很多朋友在開發應用時會忽視這一點,這樣如果将程式部署到時區設定不同的系統上(例如國外的虛拟主機服務),在運作時就會産生不同的結果。如果大家使用FxCop(包含在Windows SDK中)來檢測自己的程式集就會發現,調用日期時間的無參數ToString方法違反了Globalization類别的一條準則。這是因為無參數的ToString方法傳回結果會由目前線程的Culture(可以通過Thread.CurrentThread.CurrentCulture屬性來擷取或設定)來決定,而目前線程的Culture與系統設定相關。
可以輕松的開發出适合多地區浏覽的應用。對于一個“國際化友好”的應用程式來說,往往我們是根據用戶端的地域設定或者目前正浏覽的市場設定來顯示時間,這樣在中國的使用者和在美國的使用者就不會因為時間産生誤解。從這一點上又可以清楚地發現使用UTC時間作為存儲是多麼的重要,隻有這樣,才能友善地做到“國際化”友好,
個人認為,時間問題其實是應用程式國際化中最容易解決的問題,因為貨币會涉及到匯率換算,文字又涉及到翻譯等等,而在時間日期問題上我們隻要符合一定的良好實踐即可。我們在處理時間問題時往往都應該留個心眼,例如遇到開發過程中怎麼時間莫名其妙的差了8個小時的問題,就應該敏感地想到會不會是因為日期時間在時區問題上出現了差錯,因為我們的開發機一般總是用了中原標準時間(UTC +8)嘛。:)
之所謂得到寫這個系列的靈感,是因為一個朋友在向我回報ASP.NET AJAX中調用Web Service方法時在日期時間上出現的問題。原本我隻是想簡單地針對這個問題進行解釋(其實并不是bug,隻是因為在開發時忽視了時區問題),但是發現描述時涉及到了太多的内容,是以我想趁此機會深入一下時間方面的問題,以及在使用JavaScript和.NET Framework在開發時的要點和實踐。具體内容将在今後的文章中進行較長的描述。
本文轉自 jeffz 51CTO部落格,原文連結:http://blog.51cto.com/jeffz/59901,如需轉載請自行聯系原作者