背景
2023年10月に RFC 3339 を拡張する新たな日付時刻形式を定める RFC Draft: Date and Time on the Internet: Timestamps with additional information が IESG によって承認されました。
これは TC39 で標準化が進められている ECMAScript Temporal において、生成する文字列形式にタイムゾーンなどの追加情報を入れたいという話が発端となっています。その後 IETF SEDATE で標準化作業が進行し Java SE 8 DateTimeFormatter の ISO_ZONED_DATE_TIME が生成する ISO 8601 の独自拡張形式と互換性を持つ形で定義されました。
インターネットにおける日付時刻形式
インターネットにおいて用いられる日付時刻形式は、伝統的な RFC 9110 (RFC 5322) と現代的な RFC 3339 (ISO 8601) があります。
RFC 9110 (RFC 5322) 形式
RFC 5322: Internet Message Format に電子メールの仕様が定義されており[1]、その中に日付時刻形式についても記述されています。歴史的な経緯から RFC 9110: HTTP Semantics にこの RFC 5322 をもとにした日付時刻形式が定められており、電子メールに限らず HTTP プロトコルなどで使われています。
Date: Wed, 14 Oct 2015 07:28:00 GMT
Set-Cookie: id=a3fWa; Expires=Wed, 21 Oct 2015 07:28:00 GMT
ECMAScript においては Date.prototype.toUTCString で生成することができます。
new Date("1995-12-17T03:24:00Z").toUTCString();
// => "Sun, 17 Dec 1995 03:24:00 GMT"
RFC 3339 (ISO 8601) 形式
国や文化によらない国際標準の日付時刻形式として ISO 8601: Date and time があります。これは寛容な仕様となっており、情報交換の際には事前にプロファイルを取り決めてから使用することが想定されています。
基本形式: 19951217T032400Z
拡張形式: 1995-12-17T03:24:00Z
この ISO 8601 拡張形式をもとに RFC 3339: Date and Time on the Internet: Timestamps が定められています。ECMAScript や HTML Standard でもこの ISO 8601 拡張形式をもとにしており[2][3]、今ではインターネットにおける標準の日付時刻形式と言っても過言ではありません。
さて、経緯からわかるように RFC 3339 と ISO 8601 は厳密には異なります。大雑把ではありますがインターネットにおけるタイムスタンプの文脈でこれら日付時刻形式の話題が出た際には、だいたいその共通部分を指していると考えて基本問題はないと思われます。
ECMAScript においては Date.prototype.toISOString で生成することができます。また Date のコンストラクタでパースすることが出来ます。
new Date("1995-12-17T03:24:00Z").toISOString();
// => "1995-12-17T03:24:00.000Z"
Internet Extended Date/Time Format (IXDTF)
RFC Draft: Date and Time on the Internet: Timestamps with additional information にて新たに Internet Extended Date/Time Format (IXDTF) が定められました。RFC 3339 の Internet Date/Time Format にタイムゾーンと、キーバリューペアを持つタグを付加できます。
![2020-08-05T20:06:13+09:00[Asia/Tokyo][u-ca=japanese]](https://storage.googleapis.com/zenn-user-upload/c55e37ee31ac-20240216.png)
String Parsing, Serialization, and Formatting in ECMAScript Temporal より引用
タイムゾーン
タイムゾーンの文字列は IANA によって管理される Time Zone Database が使われることを想定しています。
政治的な理由からこのデータベースは追加、変更される可能性があります。その理由もあって処理系が知らないタイムゾーンが指定された場合は無視されることとなります。
2003-07-07T00:00:00+09:00[Bamboo_Leaf_Rhapsody]
2003-07-07T00:00:00+09:00
またタイムゾーンがオフセットと一致していない場合も無視されます。例えば本来 +02:00 オフセットを持つはずの Europe/Paris に対して別のオフセットが指定された場合 Europe/Paris はないものとして扱われます。
2022-07-08T00:14:07+01:00[Europe/Paris]
2022-07-08T00:14:07+01:00
ただしオフセットに協定世界時（UTC）Z を使った場合は無視されることはありません。
2022-07-08T00:14:07Z[Europe/Paris]
2022-07-08T02:14:07+02:00[Europe/Paris]
クリティカルフラグ
処理系に無視されるのではなく、リジェクトして欲しい場合はクリティカルフラグ ! を付けます。例えば以下はタイムゾーンとオフセットが一致していないため例外を投げることが要求されます。
2022-07-08T00:14:07+01:00[!Europe/Paris]
タグ
[key=value] の形でタグ情報を付与することが出来ます。末尾に追加することが出来、タイムゾーンの前に記述することは出来ません。
キーは小文字のみ許され[4]、バリューは大文字小文字を区別します。2024年2月現在、登録されているタグは u-ca のみです。これは Unicode BCP 47 U Extension の Unicode Calendar Identifier が用いられます。登録されるタグは今後増えていくことが想定されています。
タイムゾーン同様、処理系が知らないタグは無視されます。
1985-11-29T00:00:00+09:00[hannin=Yasu]
1985-11-29T00:00:00+09:00
同じキーのタグがあった場合、先勝ち扱いとなります。
2022-07-08T00:14:07Z[u-ca=chinese][u-ca=japanese]
2022-07-08T00:14:07Z[u-ca=chinese]
クリティカルフラグ
タイムゾーン同様に処理系に無視されるのではなく、リジェクトして欲しい場合はクリティカルフラグ ! をつけます。例えば以下のように処理系が知らないタグであったり、同じキーのタグ一方にクリティカルフラグを付けていたりする場合はリジェクトされます。
1985-11-29T00:00:00+09:00[!hannin=Yasu]
2022-07-08T00:14:07Z[!u-ca=chinese][u-ca=japanese]
2022-07-08T00:14:07Z[u-ca=chinese][!u-ca=japanese]
締め
IXDTF についてまとめてみました。今後 ECMAScript や Java を前提とした処理系に対しては使われそうな仕様ですが、各言語で実装され広く使われることになるのかはわからないですね……。
それはそれとして IXDTF が承認されたことによって JavaScript の各ランタイムで Temporal が使えるようになってきています。
早く Date の要らない世界が来て欲しいですね。
Discussion