書き方の国際規格：ISO 8601とRFC 3339
日付と時刻の書き方には、国際規格のISO 8601があります。ところが、ISO 8601は、複数の表し方や一部だけ書く形をたくさん認めていて、複雑です。
そこで、IETFのRFC 3339は、インターネットで使うためにISO 8601を絞り込んだ「プロファイル」を定めました。ISO 8601の拡張形式の部分集合で、ほとんどの項目と区切りの記号を必須にすることで、単純にしています [T1]。
RFC 3339は、「日付と時刻の書き方は、インターネットで多くの混乱と、相互運用性の問題を起こしている」と冒頭で述べています [T1]。
基本の形
2026-10-09T09:00:00+09:00
| 部分 | 例 | 意味 |
| 年-月-日 | 2026-10-09 | 年は4桁、月と日は2桁。 |
| T | T | 日付と時刻の区切り。 |
| 時:分:秒 | 09:00:00 | 時は00〜23、分と秒は00〜59（うるう秒のみ60）。 |
| オフセット | +09:00 | UTCとのずれ。 日本時間は+09:00。 UTCそのものならZ。 |
RFC 3339の形式は、「年-月-日」の後に「T」、続いて「時:分:秒」、最後にUTCとのずれ（オフセット）を付けます。「T」は日付と時刻の区切りです [T1]。
ルールは次のとおりです [T1]。
- 年は必ず4桁：2桁の年は、あいまいさの原因になるため非推奨。インターネットのプロトコルは、4桁の年を生成しなければならない
- 時は00〜23：ISO 8601では「24」も認められているが、混乱を減らすため、この形式では使わない
- 秒の小数は任意：必要なら、「.52」のように、小数点以下を付けられる（たとえば「23:20:50.52」）
- うるう秒は、秒に「60」と書く：うるう秒のときだけ60が現れる
- 曜日は書かない：曜日は日付から計算でき、間違った曜日が混ざる可能性があるため
UTCとの「ずれ」：Zと+09:00
時刻の最後に付くUTCとのずれを、「オフセット」と呼びます。次の書き方があります [T1]。
- Z：UTCそのもの（オフセット00:00）。「ズールー」と読むことがある
- +09:00 / -08:00：UTCとのずれ。計算は、「現地時刻 − UTC」。たとえば、+09:00は、UTCより9時間進んでいる
RFC 3339の例では、「18:50:00-04:00」は、「22:50:00Z」と同じ瞬間です。
「1996-12-19T16:39:57-08:00」は、「1996-12-20T00:39:57Z」と同じです [T1]。
日本時間の例にすると、「2026-10-09T09:00:00+09:00」は、「2026-10-09T00:00:00Z」と同じ瞬間です。
注記：日本時間の例は、RFC 3339の計算規則（現地時刻からオフセットを引くとUTC）を
日本に当てはめた私の例です。
「-00:00」という特別な書き方
RFC 3339には、UTCは分かるが現地時間のずれが分からないときに使う、特別な書き方があります。
「-00:00」と書きます。これは、「Z」や「+00:00」とは意味が違います。「Z」や「+00:00」は、UTCを基準にしたいという意味を含みます [T1]。
並べ替えができる：この形式の大きな利点
RFC 3339の形式は、「年、月、日、時、分、秒」と、大きい単位から小さい単位へ並んでいます。そのため、時間帯（オフセット）が同じで小数点以下の桁数も同じなら、文字列として並べ替えるだけで、時間順に並びます [T1]。
ログの検索や、ファイル名に日時を使うときにも便利です。
「10/11/1996」は使わない
RFC 3339は、「10/11/1996」という書き方は国によって解釈が違うため、世界でのやり取りにはまったく向かないと明記しています [T1]。
日本では、「2026/10/09」のように、年が先頭に来る書き方が一般的です。ただ、システムの間でやり取りする場合は、RFC 3339のような決まった形式を使うほうが誤解を防げます。
JSONには、日付型がない
このシリーズの「データ形式」の記事でも見たとおり、JSONが扱える型は、文字列、数値、真偽値、null、オブジェクト、配列の6つだけです [T6]。日付や時刻の専用の型はありません。
そのため、日付や時刻は文字列として書くことになります。このとき、RFC 3339の形式を使うことが一般的な選択肢です。
注記：「JSONの日付は、RFC 3339の形式で書くのが一般的」という点は、
JSONに日付型がないこと（RFC 8259）と、RFC 3339がインターネットの
標準的な書き方であることから整理した情報です。
RFC 8259は、日付の書き方を定めていません。
RFC 3339が扱わないこと
RFC 3339が対象にするのは、「ある瞬間」（タイムスタンプ）の表し方です。期間や、「毎週月曜の10時」のような繰り返しの予定は扱いません。
また、すべての時刻には、UTCとの関係（オフセット）がはっきり示されている前提で、夏時間のような地域の時刻のルールには立ち入らない、と説明しています [T1]。
RFC 3339は、2002年の文書です。その後、RFC 9557という文書で追加の情報（タイムゾーン名など）を付ける拡張が定められ、RFC 3339はこの文書によって更新されています [T1]。
注記：RFC 9557の中身は、今回読んでいません。
RFC 3339のページに、更新した文書として記載されている、という点までを確認しています。
発注の前に確認したいこと
- システム間でやり取りする日時は、RFC 3339（ISO 8601）形式か。年は4桁か
- オフセット（+09:00やZ）を付けているか。付いていない日時を受け取ったときの扱いは決まっているか
- CSVやExcelに出力する日時の形式は何か（このシリーズの「文字コード」「データ形式」の記事も参照）
注記：この3点は、RFC 3339の内容から整理した確認項目です。
資料がこの形のチェックリストを示しているわけではありません。
参照元
[T1] IETF, RFC 3339: Date and Time on the Internet: Timestamps（2002年。RFC 9557により更新） — https://datatracker.ietf.org/doc/html/rfc3339
[T6] IETF, RFC 8259: The JavaScript Object Notation (JSON) Data Interchange Format — https://datatracker.ietf.org/doc/html/rfc8259
コメント