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

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

不管活在哪一個時區，對於日期時間，電腦系統內部儲存的其實都是「相對於 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 這個數字就推測該不該幫它調整一下。

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

如果需要改，那這部份還真的有點麻煩呢。

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