⏰

RFC 9557: インターネット上の日付と時刻: 追加情報を含むタイムスタンプ

2024/04/30に公開

RFC

tech

要旨

本文書は、タイムゾーンを含む追加情報を表現するために、RFC 3339で定義されているタイムスタンプ書式の拡張を定義する。

この拡張は、ローカル・オフセットZの具体的な解釈において、RFC 3339を更新するもので、もはや「UTCが指定された時刻の優先参照点であることを意味する」とは理解されなくなった。

本文書の位置付け

本文書は、インターネット標準化過程の文書である。

この文書はInternet Engineering Task Force (IETF)の成果物である。IETFコミュニティのコンセンサスを表すものである。公開レビューを受けており、Internet Engineering Steering Group (IESG)によって公開が承認されている。インターネット標準の詳細については、RFC 7841のセクション2を参照のこと。

本文書の現在のステータス、正誤表、および文書に対するフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc9557 で入手できる。

著作権表示

本文書は、BCP 78および文書の発行日において有効なIETF文書に関するIETFトラストの法的規定(https://trustee.ietf.org/license-info)に従うものとする。これらの文書には、本文書に関するあなたの権利と制限が記載されているため、注意深く確認して欲しい。文書から抽出されたコード・コンポーネントには、トラスト法的条項のセクション4.eに記載されている改訂BSDライセンスのテキストを含まなければならず、改訂BSDライセンスに記載されているように保証なしで提供する。

1. はじめに

日付と時刻は、サーバ側のログ記録からカレンダーやスケジュール設定に至るまで、非常に多様なインターネット・アプリケーションで使われている。

時間の各瞬間は、タイムスタンプを使用して記述的テキスト書式で表すことができる。[ISO8601-1:2019]は、広く採用されているタイムスタンプ書式を標準化しており、その以前のバージョン[ISO8601:1988]は、インターネット日付/時刻書式[RFC3339]の基礎を形成した。しかし、この書式は、タイムスタンプに追加の関連情報をほとんど含めることができない。それ以上に、タイムスタンプに関連する文脈情報は、個別に処理するか、非標準的な方法で添付する必要がある。

⚠️ 日付/時刻書式 (ISO 8601 / RFC 3339)

date-time-format

これは、夏時間への移行などのイベントを考慮するために、そのような時間の各瞬間を関連するタイムゾーン名で処理するアプリケーションにとって差し迫った問題である。このようなアプリケーションの多くは、タイムスタンプにタイムゾーンを非標準書式で付加しており、そのうちの少なくとも1つはかなり採用されている[JAVAZDT]。さらに、アプリケーションによっては、タイムスタンプを表現するカレンダー・システムなど、さらに多くの情報をタイムスタンプに添付したい場合がある。

本文書は、[RFC3339]で定義されたタイムスタンプ書式の拡張し、タイムゾーンを含む追加情報を表すことを定義する。

これは、ローカル・オフセットZの具体的な解釈において、[RFC3339]を更新するものである。もはや、「UTCが指定された時間の優先参照点であることを意味する」ものとして理解されなくなった。セクション2を参照のこと。

1.1. 範囲

[RFC3339]は、インターネットで日付と時刻を表すタイムスタンプの構文を定義している。本文書は、以下の特性を実現する拡張構文を定義する。

拡張サフィックスは完全にオプションであり、既存の[RFC3339]タイムスタンプをこの書式と互換にする。
この書式は、タイムスタンプにタイムゾーン名を付加するための既存の一般的な構文[JAVAZDT]と互換性がある。
この書式は、タイムスタンプに追加情報を付加する一般的な方法を提供する。

この書式をインターネット拡張日付/時刻書式(IXDTF)と呼ぶ。

本文書は、セマンティックな結果が(過去または将来の)UTC時刻を参照する固定タイムスタンプではなくなる書式の拡張には対応しない。例えば、以下のような問題には対応していない。

あるタイムゾーンのローカル時間として示される将来の時刻。そのタイムゾーンの定義の変更(夏時間の制定または廃止の政治的決定など)は、タイムスタンプで表される時刻の瞬間に影響を与える。
「フローティング時間」、つまり、解釈すべきUTCオフセットやタイムゾーンを説明する情報のないローカル時間、または
国際原子時(TAI)など、UTCとは異なるタイムスケールを使用する。

しかし、固定タイムスタンプを補強する追加情報は、UTCオフセットとタイムゾーン名の間のような、タイムスタンプの意図と実際の情報の間の不一致を検出するのに十分な場合がある。例えば、以下のような理由で不一致が生じる可能性がある:

前述したように、政治的な決定、
タイムゾーンの定義の更新が、タイムスタンプの生成側と受信側で異なる時間に適用される、または
タイムスタンプを生成および消費するプログラムのエラー。

IXDTF文字列で利用可能な情報は、一般的に不一致を解決するのに十分ではないが、そのような解決に十分な情報を得るために、何らかのアウトオブバンド処理を開始するために使用できる。

ここで示唆されている要件のいくつかに対処するために、将来の関連仕様では、[RFC3339]に記述されているものと同様の文字列の構文とセマンティクスを定義するかも知れない。本文書で定義されている拡張構文は、そのような仕様にも役立つように設計されていることに留意する。

1.2. 定義

この文書のキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、および「OPTIONAL」は、ここに示すように、すべて大文字で表示される場合に限り、 BCP 14 [RFC2119] [RFC8174]の記述に従って解釈される。

UTC: 協定世界時(Coordinated Universal Time)は、1988年以降、国際度量衡局 (BIPM)が国際地球回転・基準系事業[IERS]が発表するうるう秒に合わせて維持している。1972年から1987年まで、UTCは全面的に世界国際事務局(BIH)によって維持されていた。1972年以前は、UTCは一般に認識されておらず、地球の自転の測定に基づいて世界時(Universal Time)に追跡するさまざまな手法を使って、個々の管轄区域が常用時を決定していた。

UTCは、GMT(グリニッジ標準時)と誤って呼ばれることが多いが、これはUTCが有用な後継として設計された以前の時間スケールである。

ABNF: Augmented Backus-Naur Form(拡張バッカス・ナウア記法)の略で、[RFC5234]で定義されているように、プロトコルや言語で許容される文字列を表すために使われる書式。[RFC5234]の付録Bで定義されているルールは暗黙的にインポートされる。

IXDTF: インターネット拡張日付/時刻書式。本文書のセクション4で定義されている日付/時刻書式。

タイムスタンプ: 時間における特定の瞬間の明確な表現。

UTCオフセット: 現地時間とUTCの差。通常、負または正の時と分で指定される。例えば、2023年の冬、米国ニューヨーク州ニューヨーク市のローカル時間はUTCから5時間遅れており、UTCオフセットは-05:00となる。

Z: 時刻に適用される場合、UTCオフセット00:00を示すサフィックス。ICAOのフォネティック・アルファベット表現「Z」から「ズールー」(Zulu)と発音されることが多い。(定義は[RFC3339]のセクション2によるもの。言及されている発音アルファベットについては、国際民間航空機関(ICAO)の文書[ICAO-PA]を参照のこと。)

タイムゾーン: 特定の場所や地域のローカル時間とUTCの関係を表す一連のルール。タイムゾーンは数学的には、タイムスタンプをUTCオフセットにマッピングする関数と考えることができる。タイムゾーンは、タイムスタンプをローカル時間に決定論的に変換することができる。タイムゾーンはまた、ローカル時間をタイムスタンプに変換するために逆方向にも使うこともできる。ただし、近隣の夏時間の変更やタイムゾーンのUTCオフセットに対する他の変更により、ローカル時間によってはタイムスタンプがゼロまたは複数になる可能性があることに留意する。タイムスタンプのUTCオフセットは、関連する他のタイムスタンプのUTCオフセットについて何も主張しない(したがって、「1日後」のようなローカル時間の操作を実行するのには適していない)が、タイムゾーンは、ローカル時間の差に基づいて新しいタイムスタンプを導出する方法も定義する。例えば、「カリフォルニア州サンフランシスコのタイムスタンプより1日後」を計算するには、サンフランシスコのローカル時間のUTCオフセットが1日ごとに変わる可能性があるため、タイムゾーンが必要である。

IANAタイムゾーン: IANA[TZDB] [BCP175]が管理するタイムゾーン・データベース(tzまたはzoneinfoと呼ばれることが多い)に含まれる名前付きタイムゾーン。ほとんどのIANAタイムゾーンは、同じタイムゾーンのルールを共有する特定の地域(ヨーロッパ/パリ、アジア/東京など)の最大の都市にちなんで命名されている[TZDB-NAMING]。

名前付きIANAタイムゾーンに定義されたルールは、時間の経過とともに変更されることがある。名前付きIANAタイムゾーンの使用は、解釈の時点で最新のルールが適用されることを意図している。タイムゾーン名を使用することによって伝達される追加情報は、IANAタイムゾーン・データベースに記録されているルールの変更に伴って変更される。

オフセット・タイムゾーン: 特定のUTCオフセット(例: +08:45)で定義され、例えば、[RFC3339]タイムスタンプで使用されるのと同じ数値UTCオフセット書式を名前として使用してシリアル化されたタイムゾーン。以下に例を示す。

2022-07-08T00:14:07+08:45[+08:45]

タイムスタンプのオフセットを繰り返さないサフィックスのオフセットは矛盾する(セクション3.4を参照)。

本文書では、java.time.ZonedDateTime[JAVAZDT]との下位互換性のために、オフセット・タイムゾーンを使用したシリアル化がサポートされているが、オフセット・タイムゾーンの使用は強く推奨されない。特に、入力にタイムゾーンのサフィックスを必要とする他のプログラムを満たすために、プログラムはタイムスタンプのUTCオフセットをオフセット・タイムゾーンにコピーしてはならない(MUST NOT)。これを行うと、その場所のタイムスタンプのUTCオフセットは決して変更されないことが不適切に主張することになり、提供されたタイムスタンプから新しいタイムスタンプを加算、減算、または他の方法で導出するプログラムにおいて、誤った計算を引き起こす可能性がある。例えば、2020-01-01T00:00+01:00[Europe/Paris]では、サマータイム(夏時間)を調整しながら、プログラムにタイムスタンプに6か月を追加させる。しかし、同じ計算を2020-01-01T00:00+01:00[+01:00]に適用すると、ヨーロッパ/パリのタイムゾーンで1時間ずれた誤った結果が生み出される。

CLDR: 共通ロケール・データ・リポジトリ[CLDR]、アプリケーションに位置データを提供するUnicodeコンソーシアムのプロジェクトである。

タイムスケールの詳細については、[RFC1305]の付録E、[ISO8601:1988]のセクション3、および適切なITU文書[ITU-R-TF.460-6]を参照のこと。(注: [RFC1305]は[RFC5905]によって廃止され、ここで参照されている付録Eは含まれていない。)

2. RFC 3339の更新

2.1. 背景

[RFC3339]のセクション4.3は、Zまたは+00:00として指定されたオフセットは、「UTCが指定された時刻の優先参照点である」ことを意味すると述べている。オフセット-00:00は、「UTCの時刻は分かっているが、ローカル時間へのオフセットは不明」であることを表現する方法として提供している。

このルールは、[RFC5322]のセクション3.3で述べられており、[RFC2822]のセクション3.3で以前に紹介された、電子メールヘッダの日付/時刻情報のための同様の規約を反映している。このメールヘッダ規約は実際に使用されているが、[RFC3339]への適応は、[ISO8601:2000]およびそれ以降のバージョンが実際には-00:00が許可されていないという事実によって、常に損なわれていた。

そのため、-00:00のセマンティクスを表現する必要がある実装では、代わりにZを使用する傾向があった。

2.2. RFC 3339の更新

本仕様では、[RFC3339]のセクション4.3を更新し、オフセットZを-00:00と同じ意味に解釈する実際の慣行、つまり「UTCの時刻は分かっているが、ローカル時間へのオフセットは不明」に合わせている。

[RFC3339]のセクション4.3は以下のように修正する。

UTCの時刻は分かっているが、ローカル時間へのオフセットが不明な場合、これは「Z」のオフセットで表すことができる。(この仕様のオリジナル・バージョンは、この目的のために-00:00を提供していたが、これは[ISO8601:2000]では認められておらず、相互運用性が低い。[RFC5322]のセクション3.3では、メールに関連する規約を記述しているが、この規約にはこの問題はない。) これは、オフセットが+00:00であることとは、意味的に異なり、UTCが指定された時刻の優先参照点であることを意味する。

2.3. ノート

ローカル・オフセット+00:00の意味は更新されないことに留意すること。これは、UTCが指定された時刻の優先参照点であるという意味を保持する。

また、[ISO8601:2000]以降がローカル・オフセットとして-00:00を許可していないという事実が、この機能を使用することで達成できる相互運用性のレベルが下げていることにも留意する。ただし、本仕様ではこの構文を正式に非推奨とするものではない。[RFC3339]の更新に伴う、ローカル・オフセットZを代わりに使用すべきである。

3. インターネット拡張日付/時刻書式 (IXDTF)

このセクションでは、タイムスタンプ拡張のサフィックスのフォーマットに望ましい書式について説明し、インターネット・プロトコルで使用するために[RFC3339]を拡張したIXDTFフォーマットを定義する。

3.1. 拡張情報のフォーマット

この書式では、裸の[RFC3339]タイムスタンプに加えて、重要な追加情報をアプリケーションが指定できるようにする。

タグは、キーと値を等号で区切って定義することによって行われる。タグの値には、ハイフン/マイナス記号で区切られた1つ以上の項目を指定することができる。

アプリケーションは、これらのタグをいくつでも使って、有益なタイムスタンプ・サフィックスを構築することができる。

キーは小文字のみである。特に指定がない限り、大文字と小文字を区別する。

サフィックス内の一貫性のない情報の扱いについては、セクション3.3を参照のこと。

3.2. 拡張情報タグのキーの登録

サフィックス・タグのキーは、このセクションで指定される情報を提供することによって登録される。この情報は、「Media Types」レジストリ[RFC6838]で規定されている情報に基づいてモデル化されている。確信が持てないとき、このレジストリの規定を類推して適用する必要がある。

キー識別子: キー(セクション4.1のsuffix-keyに準拠)

登録ステータス:「Provisional(暫定)」または「Permanent(恒久)」

説明: キーの簡単な説明

変更管理者: このキーの値を管理する仕様の発展を管理する人。この情報には、連絡先の電子メールアドレス、ディスカッション・リスト、関連するウェブページ(URL)への参照を含む。

参考: 参考。永続的なタグのキーの場合、これには完全な仕様を含む。暫定タグのキーの場合は、完全な仕様にならない場合でも、何らかの情報が利用できることが期待される。この場合、登録者は時間をかけてこの情報を改善することが期待される。

アンダースコア(下線)で始まるキー名は、制御された環境での実験を目的としたものであり、登録することはできない。そのようなキーは、相互交換に使用してはならず(MUST NOT)、そのような実験に参加するよう、特別に構成されていない実装では拒否しなければならない(MUST)。実験用のキーが一般的な本番環境に流出する危険性と、防止されなければならない理由の議論については、[BCP178]を参照のこと。

3.3. オプションの生成と選択的消費と重要な消費

IXDTF書式では、サフィックス・タグは常に任意である。文字列のジェネレータが望むように、追加したり省略することができる。(ただし、アプリケーションは特定のサフィックス・タグの存在を要求するかも知れない。)

特に指示がなければ、サフィックス・タグも選択項目である。受信者は、IXDTF文字列に含まれるサフィックス・タグを自由に無視することができる。その理由としては、受信者が特定のサフィックス・キーを実装していない(または知らない)、またはキーは知っているが、提供された値に基づいて動作できないなどが考えられる。

サフィックス・タグは、それがCriticalであることを示すこともある。受信者には、そのサフィックス・タグを指定されたとおりに処理できない限り、IXDTF文字列を処理してはならない(MUST NOT)。Critical(重要)なサフィックス・タグは、開始括弧の後に感嘆符を付けることで示す(セクション4.1のcritical-flagを参照)。

例えば、次のようなIXDTF文字列である:

2022-07-08T00:14:07+01:00[Europe/Paris]

は、Europe/Parisは2022年7月に+01:00のタイムゾーン・オフセットを使用していないため、内部的に一貫性がない(セクション3.4を参照)。ただし、サフィックス・タグで指定されるタイムゾーンのヒントは選択的であるため、受信者はこれを対処する必要はない。インターネット日付/時刻書式の文字列をあたかもそうであるかのように扱うことができる。

2022-07-08T00:14:07+01:00

セクション2(セクション3.4も参照)と同様、IXDTF文字列であることに留意する。
2022-07-08T00:14:07Z[Europe/Paris]
Zのローカル・オフセットは、特定の優先タイムゾーンの解釈を意味しないため、このような矛盾を示さない。2022年夏のEurope/Parisのタイムゾーン・データベースのルールを使用すると、以下と同等になる。
2022-07-08T02:14:07+02:00[Europe/Paris]

同様に、未知のサフィックスは完全に無視される場合がある:

2022-07-08T00:14:07+01:00[knort=blargel]

(受信者がサフィックス・キーknortを理解していないと仮定する)。

これとは対照的に、サフィックス・タグは選択的に使用される:

2022-07-08T00:14:07+01:00[!Europe/Paris]
2022-07-08T00:14:07Z[!u-ca=chinese][u-ca=japanese]
2022-07-08T00:14:07Z[u-ca=chinese][!u-ca=japanese]
2022-07-08T00:14:07Z[!knort=blargel]

はそれぞれ、内部的な不整合、またはCriticalとマークされた認識できないサフィックス・キー/値を持つため、受信者はこれらのIXDTF文字列を誤りと扱わなければならない(MUST)。つまり、アプリケーションがデータを拒否するか、ユーザに不一致を解決する方法を尋ねるなど、何らかのエラー処理を実行しなければならない(MUST)(セクション3.4を参照)。

アプリケーションは、不整合または認識できない選択的サフィックス・タグに対して、不整合の解決方法をユーザに尋ねるなど追加の処理を実行してもよい(MAY)ことに留意すること。選択的なサフィックス・タグに対して、そのような処理をする必要はないが、Criticalとマークされた一貫性のない、または認識されないサフィックス・タグに遭遇した場合は、拒否するか、その他のエラー処理を行う必要がある。

選択的サフィックスでサフィックス・キーが重複して使用されていることに遭遇し、この不一致に対して追加処理を行いたくないアプリケーションは、そのキーを持つ最初のサフィックスを選択しなければならない(MUST)。

2022-07-08T00:14:07Z[u-ca=chinese][u-ca=japanese]
2022-07-08T00:14:07Z[u-ca=chinese]

も同じ扱いを受ける。

3.4. 一貫性のないタイムオフセットとタイムゾーン情報

[RFC3339]のタイムスタンプには、ローカル時間とUTCのオフセットを示す時間オフセット値を含めることができる([RFC3339]のセクション4を参照。本仕様のセクション2が[RFC3339]のセクション4.3を更新していることに留意する)。

このような時間オフセット値に含まれる情報は、IXDTFタイムスタンプのタイムゾーン・サフィックスに含まれる情報と一致しない可能性がある。

例えば、カレンダー・アプリケーションは、特定のタイムゾーンでの遠い将来の会議を表すIXDTF文字列を格納することができる。その後、タイムゾーンの定義が変更され、サマータイムが廃止された場合、当初は一貫していたIXDTF文字列が不整合になる可能性がある。

時間オフセットとタイムゾーン・サフィックスの間に矛盾がある場合、タイムゾーン・サフィックスにCriticalフラグが使用されていれば、アプリケーションはその不整合に対処しなければならない(MUST)。Criticalフラグが使用されていない場合、不整合に対処してもよい(MAY)。不一致に対処するには、タイムスタンプを拒否するか、ユーザ入力やプログラム化された動作などの追加情報を介して不一致を解決することが必要になる場合がある。

例えば、図1のIXDTFタイムスタンプは00:14:07 UTCを表し、時間オフセット+00:00のローカル時間を示す。しかし、Europe/Londonは2022年7月にオフセット+01:00を使用したため、タイムスタンプは一致しない。最初のケースは、アプリケーションが不一致に対処しなければならない(MUST)(タイムゾーン・サフィックスがCriticalとマークされている)ケースであり、2番目のケースは不一致に対処してもよい(MAY)(タイムゾーン・サフィックスは選択可能)ケースである。

2022-07-08T00:14:07+00:00[!Europe/London]
2022-07-08T00:14:07+00:00[Europe/London]

図1: 一致しないIXDTFタイムスタンプ

セクション2によって更新された[RFC3339]のセクション4.3に従って、IXDTFタイムスタンプは、数値のタイムゾーン・オフセットの代わりにZを使用することで、[RFC3339]の部分でローカル時間情報を示すことを省略できる。図2のIXDTFタイムスタンプ(図1の文字列と同じ瞬間を表す)は、[RFC3339]部分で特定のローカル時間もローカル・オフセットもアサートしていないため、矛盾はない。代わりに、これらの文字列を受け取るアプリケーションは、タイムゾーン・サフィックスのルールを使用してローカル・オフセットとローカル時間を計算することができる。図2の例では、Europe/Londonのように、図1と同様に、タイムゾーン・サフィックスがCritical(つまり、アプリケーションがタイムゾーン情報を理解する必要があることを意図している)とマークされたケースと、選択可能とマークされたケースがある。これは、追加情報としてのみ提供される。

2022-07-08T00:14:07Z[!Europe/London]
2022-07-08T00:14:07Z[Europe/London]

図2: IXDTFタイムスタンプに矛盾はない

セクション2によれば、同じ意味を持つため、Zの代わりに-00:00を使用してもよいが、-00:00は[ISO8601:2000]以降では許可されていないため、Zが望ましいことに留意する。

4. RFC 3339への構文拡張

4.1. ABNF

以下のルールは、[RFC3339]で定義されているABNF構文を拡張し、オプションのサフィックスを含めることができるようにしたものである。

インターネット拡張日付/時刻書式(IXDTF)は、ルールdate-time-extで記述する。

date-timeとtime-numoffsetは[RFC3339]のセクション5.6からインポートされ、ALPHAとDIGITは[RFC5234]の付録B.1からインポートされている

time-zone-initial = ALPHA / "." / "_"
time-zone-char    = time-zone-initial / DIGIT / "-" / "+"
time-zone-part    = time-zone-initial *time-zone-char
                    ; but not "." or ".."
time-zone-name    = time-zone-part *("/" time-zone-part)
time-zone         = "[" critical-flag
                        time-zone-name / time-numoffset "]"

key-initial       = lcalpha / "_"
key-char          = key-initial / DIGIT / "-"
suffix-key        = key-initial *key-char

suffix-value      = 1*alphanum
suffix-values     = suffix-value *("-" suffix-value)
suffix-tag        = "[" critical-flag
                        suffix-key "=" suffix-values "]"
suffix            = [time-zone] *suffix-tag

date-time-ext     = date-time suffix

critical-flag     = [ "!" ]

alphanum          = ALPHA / DIGIT
lcalpha           = %x61-7A

図3: RFC 3339の拡張のABNF構文

タイムゾーンは構文的にはサフィックス・タグと似ているが、等号が含まないことに留意する。この特殊なケースは、タイムゾーン・タグにのみ使用できる。

time-zone-partのABNF定義は「.」と「..」に一致するが、どちらも明示的に除外される(time-zone-partに関する以下の注記を参照)。

time-zone-nameはIANAタイムゾーンの名前であることを目的としている。生成者と受信者は、異なるリビジョンのタイムゾーン・データベースを使用している場合、受信者はそのようなIANAタイムゾーン名を認識していない可能性があるため、そのような状況は他の不一致と同様に扱うべきである。

注: 本稿執筆時点では、各time-zone-partの長さは、[TZDB-NAMING]のルールにより、最大14文字に制限されている。あるプラットフォームはこの制限を強制しており、別のプラットフォームのタイムゾーン名はこの制限を超えることが知られている。time-zone-nameは最終的にローカル・データベースで検索されるため、その長さを管理する必要があるため、図3のtime-zone-partの生成は意図的に許容されている。

4.2. 例

このセクションでは、インターネット拡張日付/時刻書式 (IXDTF)の例をいくつか示す。

1996-12-19T16:39:57-08:00

図4: タイムゾーン・オフセットを含むRFC 3339の日付と時刻

図4は、1996年12月19日の16時間後の39分57秒を表しており、UTCからのオフセットは-08:00である。これは、UTCで表した1996-12-20T00:39:57Zと同じ瞬間であることに留意する。

1996-12-19T16:39:57-08:00[America/Los_Angeles]

図5: タイムゾーン名の追加

図5は、前の例とまったく同じ瞬間の時刻を表しているが、タイムゾーンを考慮するアプリケーションのため、それに関連する人間のタイムゾーン(「Pacific Time」)を追加で指定している。

1996-12-19T16:39:57-08:00[America/Los_Angeles][u-ca=hebrew]

図6: ヘブライ暦に投影

図6は、まったく同じ瞬間の時刻を表しているが、カレンダー対応アプリケーション(セクション5を参照)には、ヘブライ暦で投影するよう通知している。

1996-12-19T16:39:57-08:00[_foo=bar][_baz=bat]

図7: 実験用タグの追加

図7は、図4に基づき、先頭のアンダースコアで実験用と識別されるキーを使用して、サフィックスで2つの追加情報を宣言している。これらのタグ・キーを利用する管理実験に参加する実装は、これらの情報を解釈できる。

5. u-caサフィックス・キー: カレンダーの認識

可能なサフィックス・キーのうち、u-caというサフィックス・キーは、日付/時刻を表示するのに適したカレンダーを示すために割り当てられている。

カレンダーは、日付がどのようにカウントされ、実装によって消費されるかを定義するルールの集合である。このサフィックス・キーに許容されるサフィックスの値の集合は、Unicode Calendar Identifier[TR35] に定義されている値の集合である。[CLDR-LINKS]は、安定した開発ステージと特定の開発ステージの両方の[CLDR]に関する最新情報へのリンクを提供する。

6. IANAに関する考慮事項

IANAは、「Internet Date/Time Format」というタイトルの新しいレジストリ・グループに「Timestamp Suffix Tag Keys」というレジストリを作成した。レジストリの各エントリは、セクション3.2で説明されている情報で構成される。レジストリの初期内容を表1に示す。

キー識別子	登録状況	説明	変更者	参考文献
u-ca	恒久	プレゼンテーションの推奨カレンダー	IETF	RFC 9557のセクション5

表1: タイムスタンプ・サフィックス・タグ・キー・レジストリの初期内容

登録ポリシー[BCP26]は、恒久的なエントリーは「Specification Required (仕様要求)」、暫定エントリーの場合は「Expert Review (専門家レビュー)」である。後者の場合、専門家は、まだ完全でなくても、公開されていなくても、基本仕様が存在することを確認するよう指示される。

専門家はまた、一般に適用可能なセマンティクスを示唆するキー識別子の割り当てを控えめにし、広く使用される可能性が高く、キー識別子の簡潔性をうまく活用できるサフィックス・キー用に確保しておくことも指示されている。専門家が展開され、使用されているキー識別子を認識した場合、登録することで将来の衝突を回避できると判断すれば、専門家が自ら登録を開始することもできる。

7. セキュリティに関する考慮事項

7.1. 過剰な情報開示

タイムスタンプにさまざまな付随情報を含める能力は、過剰な開示につながるかも知れない。過剰な開示の可能性のある例は、[RFC3339]のセクション7で示されている。同様に、暦法や選択された言語に関する情報を漏らすことは、データ最小化の原則 [DATA-MINIMIZATION]で許可される以上に、タイムスタンプの作成者に関する情報を提供するかも知れない。より一般的に言えば、IXDTFタイムスタンプの生成者は、タイムスタンプに追加される情報が、この情報の受信者に開示するのが適切かどうかを検討する必要があり、受信者が生成者の管理下にない場合は、このような開示を最小限に抑える側に回る必要がある。

7.2. データ書式の実装の脆弱性

データ書式の構文を拡張する場合、その書式を解析・処理する実装に新たな脆弱性が生じる可能性があるのはいつものことである。IXDTF構文に関して、通常とは異なる懸念事項を引き起こすような考慮事項は知られていない。

7.3. 一貫性のないデータでの運用

IXDTF文字列のさまざまな部分で提供される情報は、この仕様で定義されている拡張 (例えば、セクション3.4を参照)と、まだ定義されていない将来の拡張の両方で、興味深い点で矛盾している可能性がある。セキュリティ目的で、複数の当事者間で一貫性のある解釈が必要な場合(例えば、アクセス制御情報のパラメータとしてタイムスタンプが埋め込まれている場合)、このような一貫性のないデータの解決方法が十分に理解され共有されている拡張のみを採用することができる。

8. 参考文献

8.1. 引用規格

[BCP175] Best Current Practice 175, <https://www.rfc-editor.org/info/bcp175>. At the time of writing, this BCP comprises the following: Lear, E. and P. Eggert, "Procedures for Maintaining the Time Zone Database", BCP 175, RFC 6557, DOI 10.17487/RFC6557, February 2012, <https://www.rfc-editor.org/info/rfc6557>.

[BCP178] Best Current Practice 178, <https://www.rfc-editor.org/info/bcp178>. At the time of writing, this BCP comprises the following: Saint-Andre, P., Crocker, D., and M. Nottingham, "Deprecating the "X-" Prefix and Similar Constructs in Application Protocols", BCP 178, RFC 6648, DOI 10.17487/RFC6648, June 2012, <https://www.rfc-editor.org/info/rfc6648>.

[BCP26] Best Current Practice 26, <https://www.rfc-editor.org/info/bcp26>. At the time of writing, this BCP comprises the following: Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.

[RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, <https://www.rfc-editor.org/info/rfc3339>.

[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <https://www.rfc-editor.org/info/rfc5234>.

[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, DOI 10.17487/RFC6838, January 2013, <https://www.rfc-editor.org/info/rfc6838>.

[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

8.2. 参考規格

[CLDR] Unicode CLDR, "Unicode CLDR Project", <https://cldr.unicode.org>.

[CLDR-LINKS] Unicode CLDR, "Stable Links Info", <https://cldr.unicode.org/stable-links-info>.

[DATA-MINIMIZATION] Arkko, J., "Emphasizing data minimization among protocol participants", Work in Progress, Internet-Draft, draft-arkko-iab-data-minimization-principle-05, 10 July 2023, <https://datatracker.ietf.org/doc/html/draft-arkko-iab- data-minimization-principle-05>.

[ICAO-PA] International Civil Aviation Organization, "Annex 10 to the Convention on International Civil Aviation: Aeronautical Telecommunications; Volume II Communication Procedures including those with PANS status", 7th ed., July 2016, <https://store.icao.int/annex-10-aeronautical-telecommunications-volume-ii-communication-procedures- including-those-with-pans-status>.

[IERS] IERS, "International Earth Rotation Service Bulletins", <https://www.iers.org/IERS/EN/Publications/Bulletins/bulletins.html>.

[ISO8601-1:2019] ISO, "Date and time -- Representations for information interchange -- Part 1: Basic rules", ISO 8601-1:2019, February 2019, <https://www.iso.org/standard/70907.html>.

[ISO8601:1988] ISO, "Data elements and interchange formats -- Information interchange -- Representation of dates and times", ISO 8601:1988, June 1988, <https://www.iso.org/standard/15903.html>. Also available from <https://nvlpubs.nist.gov/nistpubs/Legacy/FIPS/fipspub4-1-1991.pdf>.

[ISO8601:2000] ISO, "Data elements and interchange formats -- Information interchange -- Representation of dates and times", ISO 8601:2000, December 2000, <https://www.iso.org/standard/26780.html>.

[ITU-R-TF.460-6] ITU-R, "Standard-frequency and time-signal emissions", ITU-R Recommendation TF.460-6, February 2002, <https://www.itu.int/rec/R-REC-TF.460/en>.

[JAVAZDT] Oracle, "Class DateTimeFormatter: ISO_ZONED_DATE_TIME", <https://docs.oracle.com/javase/8/docs/api/java/time/ format/DateTimeFormatter.html#ISO_ZONED_DATE_TIME>.

[RFC1305] Mills, D., "Network Time Protocol (Version 3) Specification, Implementation and Analysis", RFC 1305, DOI 10.17487/RFC1305, March 1992, <https://www.rfc-editor.org/info/rfc1305>.

[RFC2822] Resnick, P., Ed., "Internet Message Format", RFC 2822, DOI 10.17487/RFC2822, April 2001, <https://www.rfc-editor.org/info/rfc2822>.

[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, DOI 10.17487/RFC5322, October 2008, <https://www.rfc-editor.org/info/rfc5322>.

[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, <https://www.rfc-editor.org/info/rfc5905>.

[TR35] Davis, M., Ed., "Unicode Technical Standard #35: Unicode Locale Data Markup Language (LDML)", <https://www.unicode.org/reports/ tr35/#UnicodeCalendarIdentifier>.

[TZDB] IANA, "Time zone and daylight saving time data", <https://data.iana.org/time-zones/tz-link.html>.

[TZDB-NAMING] IANA, "Theory and pragmatics of the tz code and data", <https://data.iana.org/time-zones/theory.html>.

謝辞

本仕様は、ECMA TC39、特にTemporalの提案の準備された作業の恩恵を受けている。

⚠️ Temporalを試す方法

ブラウザの開発画面を開いて、APIドキュメントにアクセスすると、コンソールで試すことができる。

temporal

npmを使った方法例は次のとおり。

% mkdir temporal-api
% cd temporal-api
% npm init
% npm install @js-temporal/polyfill
% cat << END >> demo.mjs
import { Temporal } from "@js-temporal/polyfill";

const now = Temporal.Now.plainDateTimeISO();
console.log(now.toString());
END
% node demo.mjs
2024-04-29T10:49:04.818744806

リチャード・ギブソンとジャスティン・グラントは、編集上の改善を行った。SEDATE WG議長のマーク・マクファデンとブロン・ゴンドワナは(後者はCALEXT WG議長も兼務)、マルチSDO環境での運用に必要な体制の構築に貢献した。ジョン・クレンシンは本仕様の開発に積極的に参加し、大幅な改善をもたらした。著者らはまた、ADレビューと開発プロセスにおける全体的な指導を行なったフランチェスカ・パロンビーニに特に感謝したい。

貢献者

ジャスティン・グラント
メール: justingrant.ietf.public@gmail.com

著者のアドレス

ウッジュワルシャルマ
Igalia, S.L.
Bugallal Marchesi, 22, 1º
15008 A Coruña
スペイン
メール：ryzokuken@igalia.com

カールステン・ボルマン
Universität Bremen TZI
Postfach 330440
D-28359 Bremen
ドイツ
電話: +49-421-218-63921
メール: cabo@tzi.org

更新履歴

2024/4.30

GitHubで編集を提案

要旨