時區，請愛用數字形式 || William’s Blog

時區，請愛用數字形式

2007 年九月 30 日 (星期日) 11:12 pm
分類：電腦
標籤： programming, RSS

前一篇文章〈華文世界 RSS 亂象〉點名許多網站的 RSS/Atom 日期格式問題。刊出後不久，突然發現，被點名的 Yahoo!奇摩部落格已經將日期格式修改成：

Sat, 29 Sep 2007 09:48:59 CST

真是值得喝彩，此舉顯示 Yahoo!奇摩部落格工程師有尊重網路標準的認知（雖然另一個也被點名的 Yahoo!奇摩新聞仍然不動如山……）。沒有直接證據，不敢居功說是拙作促成這項改變，但是，既然真的有人在乎，我也願意再當一次烏鴉。

上面的例子，如果能把時區符號，從 CST 改成 +0800 就更完美了：

Sat, 29 Sep 2007 09:48:59 +0800

或是換算成格林威治時間：

Sat, 29 Sep 2007 01:48:59 GMT

因為 CST 這個時區符號，在亞洲（尤其是東亞）會認為是台北、北京、香港所在的時區（舊稱「中原標準時間」），但在其他國度，卻可能被視為美國的美中時區（請看看 RFC 822 吧），甚至你想都沒想過的時區（詳見 Time zone abbreviations 網頁）。Sun 就在 JDK API 官方文件上這麼建議：

Three-letter time zone IDs

For compatibility with JDK 1.1.x, some other three-letter time zone IDs (such as “PST”, “CTT”, “AST”) are also supported. However, their use is deprecated because the same abbreviation is often used for multiple time zones (for example, “CST” could be U.S. “Central Standard Time” and “China Standard Time”), and the Java platform can then only recognize one of them.

Atom 的時間格式 RFC 3339 也如是說：

Attempts to label local offsets with alphabetic strings have resulted in poor interoperability in the past. As a result, RFC2822 has made numeric offsets mandatory.

因此，為了避免歧義困擾，建議 RSS 還是用 GMT 或 +0800 的表述形式。至於 Atom，更是規定只能用 +08:00 這種數字形式，一勞永逸。

結論是：時區，請愛用數字形式。

如果你對電腦系統的時區議題有興趣，請參考以下幾項參考資料：

Wikipedia 的 Time zone 條目
Wikipedia 的 List of time zones 條目
Wikipedia 的 zoneinfo 條目
Sources for Time Zone and Daylight Saving Time Data

◤建議您一併閱讀以下文章：

著作授權方式：Creative Commons 條款。

追蹤留言回應：以 RSS 2.0 方式。
文章永久網址：
» http://william.cswiz.org/blog/archives/2007-09-30/timezone-format/
引用通告 (trackback)：
» http://william.cswiz.org/blog/archives/2007-09-30/timezone-format/trackback/

本站歡迎您以合乎創用CC 的方式，將文章選錄至網路書籤或社群網站，也別忘了將您寶貴的意見（尤其是延伸的評論、補充、彙整、反駁等）留言在本站。謝謝！

5 項留言回應給 “時區，請愛用數字形式”

1 Double 留言：
2007 年十月 1日於 10:25 am
我是覺得是因為你的文章的緣故，所以Yahoo變了Blog的RSS Feed，造成我的Google Reader全面更新一次，XD。
2 eric 留言：
2007 年十月 1日於 12:48 pm
由此可見，William大的部落格可是有相當的份量呢！
建議那些網管多K點資料吧！
3 william 留言：
2007 年十月 2日於 11:31 am
@Double:

DearHoney 的〈Bloglines 看 Yahoo Blog 的 RSS 終於正常了〉一文有提到類似現象，看起來，他們不只是改日期格式，也修正一些其他的 bug。只不過……改到連 <link> 和 <guid> 欄位都包上一層 <![CDATA[，似乎有點兒誇張……
4 pest 留言：
2007 年十月 4日於 10:33 pm
William 大,

想請問一下有日光節約的話，需要把 +0800 改成 +0700 之類的嗎?

如果需要改，那這部份還真的有點麻煩呢。
5 william 留言：
2007 年十月 5日於 2:42 pm
pest 大：

我認為，很有可能不必自己動手改，你的作業系統或程式庫可能早就自動幫你改了……

我對日光節約時間沒有研究，以下純屬推測。

不管活在哪一個時區，對於日期時間，電腦系統內部儲存的其實都是「相對於 January 1, 1970, 00:00:00 GMT 參考座標」（或稱為 “epoch”）的差距值（精密度可能到達 ms）。至於這個「內部時間」該如何轉換成「各時區的時間」，並且考慮到閏年、閏秒、日光節約時間等曆法因素，那就是作業系統、程式庫的責任了。

理論上來說，只要遵循正常的 API 呼叫，盡量用 API 層次的日期時間物件，少用肉眼可見的形式傳遞，應用程式應該不用為這件事情傷腦筋。像 Java 的 Calendar 就有 TimeZone 的觀念，連帶的 DateFormat 也會有。

是的，這是純就理論上來說。萬一現實沒這麼理想，可能就會出現〈美國日光節約轉換，耗費 IT 人員時間〉這則新聞所描述的慘狀…

順帶一提，為了因應美國今年六月新的日光節約時間政策，IBM 提供一份不錯的說帖，有興趣的可以參考看看：“Guidance on updating Java SDKs and JREs for Daylight Saving Time (DST) changes”。此外，“Check Java time zone settings for Daylight Saving Time” 也是一個方便的小工具。

不過，以上講的，都還沒考慮到異地網路互連的情況。譬如說，A、B 兩國可能同屬 +0800 時區，但 A 國不實施 DST，而 B 國實施；那麼，A 的電腦收到 B 送來的時間，要不要減一？B 收到 A 送來的日期，要不要加一？除非 A 和 B 彼此都知道對方的時區地理位置，否則很難單憑 +0800 這個數字就推測該不該幫它調整一下。

William’s Blog readings, ideas, feelings, photos, etc. by William Yeh