オフセットとタイムゾーンの違い
W3C（Web技術の標準を決める団体）の資料は、「ゾーンオフセットはタイムゾーンとは別のものであり、その違いは重要」と述べています [T5]。
- ゾーンオフセット：特定の時刻のUTCとの差。「Z」か「+」「-」で表す。「+09:00」など [T5]
- タイムゾーン：時刻のルール（現在と過去の両方）に付けられた識別名。例えば、「America/Los_Angeles」はアメリカの太平洋時間を表す [T5]
W3Cの資料では、タイムゾーンのデータベース（TZデータベース、IANAが管理）の識別名を使うと説明されています。同じタイムゾーンが別名を持つこともあります（例：Asia/Ulan BatorとAsia/Ulaanbaatar） [T5]。
日本のタイムゾーンの識別名は「Asia/Tokyo」です。
なぜこの違いが重要なのでしょうか。
「-04:00」はアメリカ東海岸の夏時間のことかもしれませんが、世界のほかの多くの場所を指す可能性もあります。オフセットだけでは、その時刻が、どの地域の、どのルールに従うのか分からないのです。
W3Cは、時刻のオフセットでは不十分な場面があると述べています [T5]。
注記：「-04:00は、他の多くの場所の可能性もある」という説明は、
W3Cのバグ管理システムの議論（i18n-ISSUE-92）にある説明を要約したものです。
W3Cの資料の本文は、オフセットとタイムゾーンは別のものである
という点を明示しています [T5]。
夏時間：将来の時刻は予測できない
夏時間（サマータイム）とは、季節によって時計を1時間進める制度です。RFC 3339は、その規則を「非常に入り組んでいて、地域の法律によって、予測できない時期に変わりうる」と説明しています。
そして、例えば、2005年3月23日の17時のニューヨークがUTCでいつにあたるかは、夏時間についての行政の判断に左右される可能性がある、と例を挙げています [T1]。
日本には夏時間はありません（NICTの資料では、JSTが一貫して、UTCより9時間進んでいると説明されています）[T2]。ただし、海外の拠点や海外のサービスと連携するときは、相手の地域の夏時間を考慮する必要があります。
注記：「日本には夏時間がない」という点は、NICTの資料がJSTを、UTCより9時間進んだ時刻
として説明していること、およびRFC 3339が夏時間を地域の法律で決まるものとして
説明していることからの整理です。
NICTの資料に「日本は夏時間を採用していない」という文言は、確認していません。
「過去の出来事」と「将来の予定」は保存の仕方が違う
RFC 3339は、すでに起きた出来事の「瞬間」を記録する（タイムスタンプ）には、UTCとのずれ（オフセット）を付ければ十分であり、地域のルールに立ち入らないという立場です [T1]。
一方で、将来の予定のように「その地域の現地の時刻が何時か」が大切な場面では地域のルールが関わるため、オフセットだけでは足りません [T1][T5]。
例えば、「来年の3月23日、ニューヨークの17時に会議」という予定を、今の時点のオフセットでUTCに変換して保存すると、夏時間の制度が変わったときに会議の時刻がずれる可能性があります。
この場合は、「現地の日時」と「タイムゾーンの識別名」を組にして保存するのが安全だと考えられます。
注記：最後の保存の仕方（現地の日時とタイムゾーン名を組にする）は、
RFC 3339とW3Cの資料の考え方から導いた実務上の整理です。
これらの資料が、この保存方法を直接指示しているわけではありません。
略称は使わない：JSTやESTのような書き方
RFC 3339は、時間帯をアルファベットの略称で表そうとすることは、過去に相互運用性の悪さを招いたと述べ、数字のオフセットを使うようにしています [T1]。
「JST」「EST」「CST」のような略称は、同じ略称が複数の地域を指すことがあり、誤解のもとです。タイムゾーンを指定するときは、「Asia/Tokyo」のような識別名を使うのが安全です [T5]。
注記：「同じ略称が複数の地域を指す」という具体例（CSTなど）は、一般的な知識です。
今回確認した資料内では、RFC 3339の「アルファベットの略称は相互運用性が悪い」
という指摘までを確認しています。
よくある落とし穴
- オフセットなしの日時：RFC 3339は、オフセットのない現地時刻は、地球の約24分の23の場所で解釈に失敗するため、インターネットでは許容できないと述べている [T1]
- 日付だけのつもりが、時刻を含んでいる：「2026-10-09」と「2026-10-09T00:00:00Z」は、日本時間では別の日になりうる（UTCの0時は、日本時間の9時）
- 月末・年度末の集計：どのタイムゾーンの「月末」を基準にするのかを決めていないと、UTCと日本時間とで日付がずれる。日本時間の0時〜9時は、UTCでは前の日にあたる
注記：2つ目と3つ目は、UTCと日本時間の関係（9時間）から導いた注意点です。
資料にある記述ではありません。
発注の前に確認したいこと
- データベースやログに保存する時刻の基準は何か（UTC、日本時間）。基準を仕様書に書いているか
- 画面に表示する時刻は利用者のタイムゾーンに合わせるのか、日本時間に固定するのか
- 海外拠点・海外サービスとの連携がある場合、相手の夏時間をどう扱うか
- 将来の予定（会議、締め切り、定期処理）は、「現地の日時」と「タイムゾーン名」で管理しているか
- 「月末」「日付が変わる時刻」の締めは、どのタイムゾーンの基準か
注記：この5点は、各資料の内容から整理した確認項目です。
資料がこの形のチェックリストを示しているわけではありません。
UNIX時間（1970年からの秒数）や2038年問題などは、今回の調査では扱っていません。
参照元
[T1] IETF, RFC 3339: Date and Time on the Internet: Timestamps（2002年。RFC 9557により更新） — https://datatracker.ietf.org/doc/html/rfc3339
[T2] NICT（情報通信研究機構）, 日本標準時グループ パンフレット — https://www.nict.go.jp/pamphlet/TS_j-panf.pdf
[T5] W3C, Working with Time Zones（Working Group Note, 2005年） — https://www.w3.org/TR/2005/NOTE-timezone-20051013/
コメント