Internet Engineering Task Force (IETF) U. Sharma
Request for Comments: 9557 Igalia, S.L.
Updates: 3339 C. Bormann
Category: Standards Track Universität Bremen TZI
ISSN: 2070-1721 April 2024
This document defines an extension to the timestamp format defined in RFC 3339 for representing additional information, including a time zone.
このドキュメントでは、タイムゾーンを含む追加情報を表すためにRFC 3339で定義されているタイムスタンプ形式の拡張機能を定義します。
It updates RFC 3339 in the specific interpretation of the local offset Z, which is no longer understood to "imply that UTC is the preferred reference point for the specified time".
ローカルオフセットZの特定の解釈でRFC 3339を更新します。これは、「UTCが指定された時間の優先参照ポイントであることを意味する」とは理解されていません。
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、RFC 7841のセクション2で入手できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9557.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9557で取得できます。
Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2024 IETF Trustおよび文書著者として特定された人。無断転載を禁じます。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、改訂されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。
1. Introduction
1.1. Scope
1.2. Definitions
2. Updating RFC 3339
2.1. Background
2.2. Update to RFC 3339
2.3. Notes
3. Internet Extended Date/Time Format (IXDTF)
3.1. Format of Extended Information
3.2. Registering Keys for Extended Information Tags
3.3. Optional Generation and Elective vs. Critical Consumption
3.4. Inconsistent time-offset and Time Zone Information
4. Syntax Extensions to RFC 3339
4.1. ABNF
4.2. Examples
5. The u-ca Suffix Key: Calendar Awareness
6. IANA Considerations
7. Security Considerations
7.1. Excessive Disclosure
7.2. Data Format Implementation Vulnerabilities
7.3. Operating with Inconsistent Data
8. References
8.1. Normative References
8.2. Informative References
Acknowledgements
Contributors
Authors' Addresses
Dates and times are used in a very diverse set of Internet applications, all the way from server-side logging to calendaring and scheduling.
日付と時間は、サーバー側のロギングからカレンダーやスケジューリングまで、非常に多様なインターネットアプリケーションのセットで使用されます。
Each distinct instant in time can be represented in a descriptive text format using a timestamp. [ISO8601-1:2019] standardizes a widely adopted timestamp format, an earlier version of which [ISO8601:1988] formed the basis of the Internet Date/Time Format [RFC3339]. However, this format allows timestamps to contain very little additional relevant information. Beyond that, any contextual information related to a given timestamp needs to be either handled separately or attached to it in a non-standard manner.
時間内のそれぞれの瞬間は、タイムスタンプを使用して説明的なテキスト形式で表現できます。[ISO8601-1：2019]は、広く採用されているタイムスタンプ形式を標準化し、その以前のバージョン[ISO8601：1988]がインターネットの日付/時刻形式[RFC3339]の基礎を形成しました。ただし、この形式により、タイムスタンプにはほとんど追加の関連情報が含まれていません。それを超えて、特定のタイムスタンプに関連するコンテキスト情報は、個別に処理するか、非標準的な方法で接続する必要があります。
This is a pressing issue for applications that handle each such instant in time with an associated time zone name in order to take into account events such as daylight saving time transitions. Many of these applications attach the time zone to the timestamp in a non-standard format, at least one of which is fairly well-adopted [JAVAZDT]. Furthermore, applications might want to attach even more information to the timestamp, including but not limited to the calendar system in which it should be represented.
これは、夏時間の移行などのイベントを考慮に入れるために、関連するタイムゾーン名でそのような瞬間それぞれを処理するアプリケーションの差し迫った問題です。これらのアプリケーションの多くは、タイムゾーンを標準以外の形式でタイムスタンプに添付しています。さらに、アプリケーションは、それを表現する必要があるカレンダーシステムを含むがこれらに限定されない、さらに多くの情報をタイムスタンプに添付することをお勧めします。
This document defines an extension to the timestamp format defined in [RFC3339] for representing additional information, including a time zone.
このドキュメントでは、タイムゾーンを含む追加情報を表すために、[RFC3339]で定義されているタイムスタンプ形式の拡張機能を定義します。
It updates [RFC3339] in the specific interpretation of the local offset Z, which is no longer understood to "imply that UTC is the preferred reference point for the specified time"; see Section 2.
ローカルオフセットZの特定の解釈で[RFC3339]を更新します。これは、「UTCが指定された時間の優先参照ポイントであることを意味する」とは理解されていません。セクション2を参照してください。
[RFC3339] defines a syntax for timestamps to represent date and time in the Internet. The present document defines an extension syntax that achieves the following properties:
[RFC3339]は、タイムスタンプがインターネットで日時を表すための構文を定義します。現在のドキュメントは、次のプロパティを達成する拡張構文を定義しています。
* The extension suffix is completely optional, making existing [RFC3339] timestamps compatible with this format.
* 拡張サフィックスは完全にオプションであり、既存の[RFC3339]タイムスタンプをこの形式と互換性のあるものにします。
* The format is compatible with the pre-existing popular syntax for attaching time zone names to timestamps [JAVAZDT].
* この形式は、タイムゾーン名をタイムスタンプ[JavazDT]に添付するための既存の一般的な構文と互換性があります。
* The format provides a generalized way to attach additional information to the timestamp.
* この形式は、タイムスタンプに追加情報を添付する一般化された方法を提供します。
We refer to this format as the Internet Extended Date/Time Format (IXDTF).
この形式をインターネット拡張日付/時刻形式（IXDTF）と呼びます。
This document does not address extensions to the format where the semantic result is no longer a fixed timestamp that is referenced to a (past or future) UTC time. For instance, it does not address:
このドキュメントでは、セマンティック結果が（過去または将来の）UTC時間を参照する固定タイムスタンプではなくなった形式への拡張機能を扱っていません。たとえば、対処しません。
* future time given as a local time in some specified time zone, where changes to the definition of that time zone (such as a political decision to enact or rescind daylight saving time) affect the instant in time represented by the timestamp;
* いくつかの指定されたタイムゾーンで現地時間として与えられた将来の時間。そのタイムゾーン（夏時間の節約時間を制定または取り消すという政治的決定など）の定義の変更は、タイムスタンプで表される時間の瞬間に影響します。
* "floating time", i.e., a local time without information describing the UTC offset or time zone in which it should be interpreted; or
* 「浮動時間」、つまり、UTCオフセットまたは解釈する必要があるタイムゾーンを説明する情報のない現地時間。または
* the use of timescales different from UTC, such as International Atomic Time (TAI).
* 国際原子時間（TAI）など、UTCとは異なるタイムスケールの使用。
However, additional information augmenting a fixed timestamp may be sufficient to detect an inconsistency between the intention and the actual information in the timestamp, such as between the UTC offset and time zone name. For instance, inconsistencies might arise because of:
ただし、固定されたタイムスタンプを強化する追加情報は、UTCオフセットとタイムゾーン名の間など、意図とタイムスタンプの実際の情報の間の矛盾を検出するのに十分な場合があります。たとえば、矛盾が生じる可能性があります。
* political decisions, as discussed above,
* 上記のように、政治的決定、
* updates to time zone definitions being applied at different times by timestamp producers and receivers, or
* タイムスタンプの生産者とレシーバーによって異なる時間に適用されるタイムゾーン定義の更新、または
* errors in programs producing and consuming timestamps.
* タイムスタンプの生産および消費プログラムのエラー。
While the information available in an IXDTF string is not generally sufficient to resolve an inconsistency, it may be used to initiate some out-of-band processing to obtain sufficient information for such a resolution.
IXDTF文字列で利用可能な情報は一般に矛盾を解決するのに十分ではありませんが、帯域外処理を開始して、そのような解決のための十分な情報を取得するために使用できます。
In order to address some of the requirements implied here, related specifications in the future might define syntax and semantics of strings similar to those described in [RFC3339]. Note that the extension syntax defined in the present document is designed in such a way that it can be useful for such specifications as well.
ここで暗示されている要件のいくつかに対処するために、将来の関連する仕様は、[RFC3339]に記載されているものと同様の文字列の構文とセマンティクスを定義する可能性があります。本文書で定義されている拡張構文は、そのような仕様にも役立つように設計されていることに注意してください。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
「必須」、「必要」、「必須」、「shall」、「shall」、「suff」、 "not"、 "becommended"、 "becommented"、 "may"、 "optional「このドキュメントでは、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
UTC:
UTC:
Coordinated Universal Time, as maintained since 1988 by the Bureau International des Poids et Mesures (BIPM) in conjunction with leap seconds as announced by the International Earth Rotation and Reference Systems Service [IERS]. From 1972 through 1987, UTC was maintained entirely by the Bureau International de l'Heure (BIH). Before 1972, UTC was not generally recognized, and civil time was determined by individual jurisdictions using different techniques for attempting to follow Universal Time based on measuring the rotation of the earth.
1988年以来、Bureau International des Poids et Mesures（BIPM）によって維持されている普遍的な時間は、国際的な地球の回転と参照システムサービス[IER]によって発表された数秒と並行して測定されました。1972年から1987年にかけて、UTCは完全に局の国際de L'Heure（BIH）によって維持されていました。1972年以前は、UTCは一般に認識されず、民間時間は、地球の回転の測定に基づいて普遍的な時間に従うことを試みるために、さまざまな技術を使用して個々の管轄区域によって決定されました。
UTC is often mistakenly referred to as GMT (Greenwich Mean Time), an earlier timescale for which UTC was designed to be a useful successor.
UTCは、多くの場合、GMT（Greenwich Mean Time）と誤って呼ばれます。これは、UTCが有用な後継者になるように設計された以前のタイムスケールです。
ABNF:
ABNF：
Augmented Backus-Naur Form, a format used to represent permissible strings in a protocol or language, as defined in [RFC5234]. The rules defined in Appendix B of [RFC5234] are imported implicitly.
[RFC5234]で定義されているように、プロトコルまたは言語で許容される文字列を表すために使用される形式である、拡張されたBackus-Naur形式。[RFC5234]の付録Bで定義されているルールは、暗黙的にインポートされます。
IXDTF:
ixdtf：
Internet Extended Date/Time Format, the date/time format defined in Section 4 of this document.
インターネット延長日付/時刻形式、このドキュメントのセクション4で定義されている日付/時刻形式。
Timestamp:
タイムスタンプ：
An unambiguous representation of a particular instant in time.
特定の瞬間の明確な表現。
UTC Offset:
UTCオフセット：
Difference between a given local time and UTC, usually given in negative or positive hours and minutes. For example, local time in the city of New York, NY, USA in the wintertime in 2023 was 5 hours behind UTC, so its UTC offset was -05:00.
特定の現地時間とUTCの違い。通常、負または正の時間と数分で与えられます。たとえば、2023年の冬のニューヨーク州ニューヨーク市の現地時間はUTCに5時間遅れていたため、UTCのオフセットは-05：00でした。
Z:
Z:
A suffix that, when applied to a time, denotes a UTC offset of 00:00; often pronounced "Zulu" from the ICAO phonetic alphabet representation of the letter "Z". (The definition is from Section 2 of [RFC3339]; see the International Civil Aviation Organization (ICAO) document [ICAO-PA] for the phonetic alphabet mentioned.)
時間に適用されると、UTCオフセットを00:00に示すサフィックス。多くの場合、文字「Z」のICAO音声アルファベット表現から「Zulu」と発音されます。（定義は[RFC3339]のセクション2からのものです。言及された音声アルファベットについては、国際民間航空機関（ICAO）文書[ICAO-PA]を参照してください。）
Time Zone:
タイムゾーン：
A set of rules representing the relationship of local time to UTC for a particular place or region. Mathematically, a time zone can be thought of as a function that maps timestamps to UTC offsets. Time zones can deterministically convert a timestamp to local time. They can also be used in the reverse direction to convert local time to a timestamp, with the caveat that some local times may have zero or multiple possible timestamps due to nearby daylight saving time changes or other changes to the UTC offset of that time zone. Unlike the UTC offset of a timestamp, which makes no claims about the UTC offset of other related timestamps (and which is therefore unsuitable for performing local-time operations, such as "one day later"), a time zone also defines how to derive new timestamps based on differences in local time. For example, to calculate "one day later than this timestamp in San Francisco, California", a time zone is required because the UTC offset of local time in San Francisco can change from one day to the next.
特定の場所または地域の現地時間とUTCとの関係を表す一連のルール。数学的には、タイムゾーンは、タイムスタンプをUTCオフセットにマッピングする関数と考えることができます。タイムゾーンは、タイムスタンプを現地時間に決定的に変換できます。また、現地時間をタイムスタンプに変換するために逆方向に使用することもできます。一部の現地時間には、近くの夏時間の節約時間の変化またはそのタイムゾーンのUTCオフセットのその他の変更があるため、ゼロまたは複数の可能なタイムスタンプがある可能性があります。タイムスタンプのUTCオフセットとは異なり、他の関連するタイムスタンプのUTCオフセットについて主張しません（したがって、「1日後」などのローカル時間操作を実行するのに適していません）。タイムゾーンは導出方法も定義します現地時間の違いに基づく新しいタイムスタンプ。たとえば、「カリフォルニア州サンフランシスコのこのタイムスタンプよりも1日遅れて」を計算するには、サンフランシスコの現地時間のUTCオフセットがある日から次の日に変わる可能性があるため、タイムゾーンが必要です。
IANA Time Zone:
IANAタイムゾーン：
A named time zone that is included in the Time Zone Database (often called tz or zoneinfo) maintained by IANA [TZDB] [BCP175]. Most IANA Time Zones are named for the largest city in a particular region that shares the same time zone rules, e.g., Europe/Paris or Asia/Tokyo [TZDB-NAMING].
IANA [TZDB] [BCP175]によって維持されているタイムゾーンデータベース（多くの場合TZまたはZONEINFOと呼ばれることが多い）に含まれる指名されたタイムゾーン。ほとんどのIANAタイムゾーンは、ヨーロッパ/パリまたはアジア/東京[TZDBネーミング]などのタイムゾーンルールを共有する特定の地域で最大の都市にちなんで名付けられました。
The rules defined for a named IANA Time Zone can change over time. The use of a named IANA Time Zone implies that the intent is for the rules that are current at the time of interpretation to apply: the additional information conveyed by using that time zone name is to change with any rule changes as recorded in the IANA Time Zone Database.
指名されたIANAタイムゾーンに対して定義されたルールは、時間とともに変化する可能性があります。指名されたIANAタイムゾーンの使用は、意図が解釈時に最新のルールが適用されることであることを意味します。そのタイムゾーン名を使用して伝えられる追加情報は、IANA時間に記録されたルールの変更で変更することです。ゾーンデータベース。
Offset Time Zone:
オフセットタイムゾーン：
A time zone defined by a specific UTC offset, e.g., +08:45, and serialized using as its name the same numeric UTC offset format used in an [RFC3339] timestamp, for example:
特定のUTCオフセット、たとえば+08：45で定義され、[RFC3339]タイムスタンプで使用されている同じ数値UTCオフセット形式を使用してシリアル化されたタイムゾーン：例えば：
2022-07-08T00:14:07+08:45[+08:45]
An offset in the suffix that does not repeat the offset of the timestamp is inconsistent (see Section 3.4).
タイムスタンプのオフセットを繰り返さない接尾辞のオフセットは一貫性がありません（セクション3.4を参照）。
Although serialization with offset time zones is supported in this document for backwards compatibility with java.time.ZonedDateTime [JAVAZDT], use of offset time zones is strongly discouraged. In particular, programs MUST NOT copy the UTC offset from a timestamp into an offset time zone in order to satisfy another program that requires a time zone suffix in its input. Doing this will improperly assert that the UTC offset of timestamps in that location will never change, which can result in incorrect calculations in programs that add, subtract, or otherwise derive new timestamps from the one provided. For example, 2020-01- 01T00:00+01:00[Europe/Paris] will let programs add six months to the timestamp while adjusting for summer time (daylight saving time). However, the same calculation applied to 2020-01-01T00:00+01:00[+01:00] will produce an incorrect result that will be off by one hour in the time zone Europe/Paris.
このドキュメントでは、java.time.zoneddateTime [javazdt]との逆方向の互換性のために、オフセットタイムゾーンを使用したシリアル化はサポートされていますが、オフセットタイムゾーンの使用は強く推奨されています。特に、プログラムは、タイムゾーンの接尾辞を入力する必要がある別のプログラムを満たすために、UTCオフセットをタイムスタンプからオフセットタイムゾーンにコピーしてはなりません。これを行うと、その場所のタイムスタンプのUTCオフセットが変更されないことを不適切に主張します。これにより、提供されたものから新しいタイムスタンプを追加、減算、または導き出すプログラムの計算が誤っている可能性があります。たとえば、2020-01- 01T00：00+01：00 [ヨーロッパ/パリ]により、プログラムは夏時間（夏時間の節約時間）に合わせて6か月をタイムスタンプに追加できます。ただし、2020-01-01T00：00+01：00 [+01：00]に適用される同じ計算は、タイムゾーンヨーロッパ/パリで1時間ずつオフになる誤った結果を生成します。
CLDR:
CLDR：
Common Locale Data Repository [CLDR], a project of the Unicode Consortium to provide locale data to applications.
一般的なロケールデータリポジトリ[CLDR]、アプリケーションにロケールデータを提供するユニコードコンソーシアムのプロジェクト。
For more information about timescales, see Appendix E of [RFC1305], Section 3 of [ISO8601:1988], and the appropriate ITU documents [ITU-R-TF.460-6]. (Note: [RFC1305] was obsoleted by [RFC5905], which no longer contains the Appendix E referenced here.)
タイムスケールの詳細については、[RFC1305]の付録E、[ISO8601：1988]のセクション3、および適切なITU文書[ITU-R-TF.460-6]を参照してください。（注：[RFC1305]は[RFC5905]によって廃止されましたが、ここで参照されている付録Eはもはや含まれていません。）
Section 4.3 of [RFC3339] states that an offset given as Z or +00:00 implies that "UTC is the preferred reference point for the specified time". The offset -00:00 is provided as a way to express that "the time in UTC is known, but the offset to local time is unknown".
[RFC3339]のセクション4.3は、zまたは+00：00として与えられたオフセットは、「UTCが指定された時間の優先参照ポイントであることを意味する」と述べています。オフセット-00：00は、「UTCの時間は知られていますが、現地時間へのオフセットは不明です」と表現する方法として提供されます。
This convention mirrors a similar convention for date/time information in email headers that is described in Section 3.3 of [RFC5322] and introduced earlier in Section 3.3 of [RFC2822]. This email header convention is in actual use, while its adaptation into [RFC3339] was always compromised by the fact that [ISO8601:2000] and later versions do not actually allow -00:00.
この規則は、[RFC5322]のセクション3.3で説明され、[RFC2822]のセクション3.3で紹介されたメールヘッダーの日付/時刻情報の同様の規則を反映しています。この電子メールヘッダー条約は実際に使用されていますが、[RFC3339]への適応は[ISO8601：2000]以降のバージョンでは実際に-00：00を許可していないという事実によって常に妥協されました。
Implementations that needed to express the semantics of -00:00 therefore tended to use Z instead.
したがって、-00：00のセマンティクスを表現する必要がある実装は、代わりにzを使用する傾向がありました。
This specification updates Section 4.3 of [RFC3339], aligning it with the actual practice of interpreting the offset Z to mean the same as -00:00: "the time in UTC is known, but the offset to local time is unknown".
この仕様は、[RFC3339]のセクション4.3を更新し、オフセットZを-00：00と同じと解釈するという実際の慣行と一致します。
Section 4.3 of [RFC3339] is revised to read as follows:
[RFC3339]のセクション4.3は、次のように読み取るように改訂されています。
If the time in UTC is known, but the offset to local time is unknown, this can be represented with an offset of "Z". (The original version of this specification provided -00:00 for this purpose, which is not allowed by [ISO8601:2000] and therefore is less interoperable; Section 3.3 of [RFC5322] describes a related convention for email, which does not have this problem). This differs semantically from an offset of +00:00, which implies that UTC is the preferred reference point for the specified time.
UTCの時間がわかっているが、現地時間のオフセットが不明な場合、これは「Z」のオフセットで表すことができます。（この仕様の元のバージョンは、[ISO8601：2000]によって許可されていないため、この目的のために-00：00が提供されているため、相互運用性が低くなります。問題）。これは、+00：00のオフセットと意味的に異なります。これは、UTCが指定された時間の優先参照ポイントであることを意味します。
Note that the semantics of the local offset +00:00 is not updated; this retains the implication that UTC is the preferred reference point for the specified time.
ローカルオフセット+00：00のセマンティクスは更新されていないことに注意してください。これは、UTCが指定された時間の優先参照ポイントであるという意味を保持します。
Also note that the fact that [ISO8601:2000] and later do not allow -00:00 as a local offset reduces the level of interoperability that can be achieved in using this feature; however, the present specification does not formally deprecate this syntax. With the update to [RFC3339], the local offset Z should now be used in its place.
また、[ISO8601：2000]以降は、ローカルオフセットとして-00：00を許可しないという事実は、この機能を使用する際に達成できる相互運用性のレベルを低下させることに注意してください。ただし、現在の仕様では、この構文を正式に非難していません。[RFC3339]の更新を使用すると、ローカルオフセットZをその場所で使用するようになりました。
This section discusses desirable qualities of formats for the timestamp extension suffix and defines the IXDTF format, which extends [RFC3339] for use in Internet protocols.
このセクションでは、タイムスタンプ拡張サフィックスの望ましい形式の品質について説明し、インターネットプロトコルで使用するために[RFC3339]を拡張するIXDTF形式を定義します。
The format allows applications to specify additional important information in addition to a bare [RFC3339] timestamp.
この形式により、アプリケーションは、むき出しの[RFC3339]タイムスタンプに加えて、追加の重要な情報を指定できます。
This is done by defining _tags_, each with a _key_ and a _value_ separated by an equals sign. The value of a tag can be one or more items delimited by hyphen/minus signs.
これは、それぞれ_Key_と_Value_が等しい記号で区切られた_Key_と_Value_を定義することによって行われます。タグの値は、ハイフン/マイナスサインによって区切られた1つ以上のアイテムにすることができます。
Applications can build an informative timestamp _suffix_ using any number of these tags.
アプリケーションは、これらのタグの任意の数を使用して、有益なタイムスタンプ_suffix_を構築できます。
Keys are lowercase only. Values are case-sensitive unless otherwise specified.
キーは小文字のみです。特に指定されていない限り、値は症例に敏感です。
See Section 3.3 for the handling of inconsistent information in a suffix.
接尾辞の一貫性のない情報の処理については、セクション3.3を参照してください。
Suffix tag keys are registered by supplying the information specified in this section. This information is modeled after that specified for the "Media Types" registry [RFC6838]; if in doubt, the provisions of this registry should be applied analogously.
接尾辞タグキーは、このセクションで指定された情報を提供することにより登録されます。この情報は、「メディアタイプ」レジストリ[RFC6838]に指定されたものをモデルにします。疑わしい場合は、このレジストリの規定を同様に適用する必要があります。
Key Identifier:
キー識別子：
The key (conforming to suffix-key in Section 4.1)
キー（セクション4.1の接尾辞キーに準拠）
Registration Status:
登録ステータス：
"Provisional" or "Permanent"
「暫定」または「永続的」
Description:
説明：
A very brief description of the key
キーの非常に簡単な説明
Change Controller:
Change Controller：
Who is in control of evolving the specification governing values for this key. This information can include email addresses of contact points, discussion lists, and references to relevant web pages (URLs).
このキーの値を管理する仕様を進化させることを制御している人。この情報には、連絡先ポイントのメールアドレス、ディスカッションリスト、および関連するWebページ（URL）への参照を含めることができます。
Reference:
参照：
A reference. For permanent tag keys, this includes a full specification. For provisional tag keys, there is an expectation that some information is available even if that does not amount to a full specification; in this case, the registrant is expected to improve this information over time.
参照。永続的なタグキーの場合、これには完全な仕様が含まれます。暫定タグキーの場合、それが完全な仕様に相当しなくても、いくつかの情報が利用可能であるという期待があります。この場合、登録者は時間の経過とともにこの情報を改善することが期待されています。
Key names that start with an underscore are intended for experiments in controlled environments and cannot be registered; such keys MUST NOT be used for interchange and MUST be rejected by implementations not specifically configured to take part in such an experiment. See [BCP178] for a discussion about the danger of experimental keys leaking out to general production and why that must be prevented.
アンダースコアから始まるキー名は、制御された環境での実験を目的としており、登録できません。このようなキーは、インターチェンジに使用してはならず、そのような実験に参加するように特別に構成されていない実装によって拒否される必要があります。一般的な生産に漏れている実験的な鍵の危険性と、それが防止されなければならない理由については、[BCP178]を参照してください。
For the IXDTF format, suffix tags are always _optional_. They can be added or left out as desired by the generator of the string. (An application might require the presence of specific suffix tags, though.)
IXDTF形式の場合、接尾辞タグは常に_optional_です。文字列のジェネレーターによって必要に応じて、追加または除外することができます。（ただし、アプリケーションでは、特定のサフィックスタグの存在が必要になる場合があります。）
Without further indication, suffix tags are also _elective_. The recipient is free to ignore any suffix tag included in an IXDTF string. Reasons might include that the recipient does not implement (or know about) the specific suffix key or that it does recognize the key but cannot act on the value provided.
それ以上の兆候がなければ、接尾辞タグも_elective_です。受信者は、IXDTF文字列に含まれる接尾辞タグを自由に無視できます。理由には、受信者が特定の接尾辞キーを実装していない（または知っている）、またはキーを認識しているが、提供された値に基づいて行動できないという理由が含まれる場合があります。
A suffix tag may also indicate that it is _critical_: The recipient is advised that it MUST NOT act on the IXDTF string unless it can process the suffix tag as specified. A critical suffix tag is indicated by following its opening bracket with an exclamation mark (see critical-flag in Section 4.1).
接尾辞タグは、それが_critical_であることを示している場合があります。受信者は、指定されたサフィックスタグを処理できない限り、IXDTF文字列に作用してはならないことをお勧めします。クリティカルサフィックスタグは、感嘆符のあるオープニングブラケットに従って示されます（セクション4.1の批判的フラグを参照）。
For example, IXDTF strings such as:
たとえば、次のようなixdtf文字列
2022-07-08T00:14:07+01:00[Europe/Paris]
are internally inconsistent (see Section 3.4), because Europe/Paris did not use a time zone offset of +01:00 in July 2022. However, the time zone hint given in the suffix tag is elective, so the recipient is not required to act on the inconsistency; it can treat the Internet Date/Time Format string as if it were:
ヨーロッパ/パリは2022年7月にタイムゾーンオフセットを+01：00を使用しなかったため、内部的に一貫性がありません（セクション3.4を参照）。ただし、接尾辞タグに記載されているタイムゾーンのヒントは選択的であるため、受信者は必要ありません。矛盾に基づいて行動します。インターネットの日付/時刻形式の文字列を次のように扱うことができます。
2022-07-08T00:14:07+01:00
Note that, as per Section 2 (see also Section 3.4), the IXDTF string:
セクション2（セクション3.4も参照）に従って、IXDTF文字列：
2022-07-08T00:14:07Z[Europe/Paris]
does not exhibit such an inconsistency, as the local offset of Z does not imply a specific preferred time zone of interpretation. Using the Time Zone Database rules for Europe/ Paris in the summer of 2022, it is equivalent to:
Zの局所的なオフセットは、特定の優先された解釈ゾーンを意味しないため、そのような矛盾を示すことはありません。2022年の夏にヨーロッパ/パリのタイムゾーンデータベースルールを使用すると、以下に相当します。
2022-07-08T02:14:07+02:00[Europe/Paris]
Similarly, an unknown suffix may be entirely ignored:
同様に、未知の接尾辞は完全に無視される場合があります。
2022-07-08T00:14:07+01:00[knort=blargel]
(assuming that the recipient does not understand the suffix key knort).
（受信者が接尾辞キーノートを理解していないと仮定）。
In contrast to this elective use of a suffix tag,
接尾辞タグのこの選択的使用とは対照的に、
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]
each have an internal inconsistency or an unrecognized suffix key/ value that is marked as critical, so a recipient MUST treat these IXDTF strings as erroneous. This means that the application MUST reject the data or perform some other error handling, such as asking the user how to resolve the inconsistency (see Section 3.4).
それぞれに内部矛盾または認識されていない接尾辞キー/値が重要であるとマークされているため、受信者はこれらのIXDTF文字列を誤ったものとして扱う必要があります。これは、アプリケーションがデータを拒否するか、矛盾を解決する方法をユーザーに尋ねるなど、他のエラー処理を実行する必要があることを意味します（セクション3.4を参照）。
Note that applications MAY also perform additional processing on inconsistent or unrecognized elective suffix tags, such as asking the user how to resolve the inconsistency. While they are not required to do so with elective suffix tags, they are required to reject or perform some other error handling when encountering inconsistent or unrecognized suffix tags marked as critical.
アプリケーションは、ユーザーに矛盾を解決する方法を尋ねるなど、一貫性のないまたは認識されていない選択的サフィックスタグで追加の処理を実行する場合があることに注意してください。選択的な接尾辞タグではそうする必要はありませんが、重要であるとマークされた一貫性のないまたは認識されていないサフィックスタグに遭遇した場合、他のエラー処理を拒否または実行する必要があります。
An application that encounters duplicate use of a suffix key in elective suffixes and does not want to perform additional processing on this inconsistency MUST choose the first suffix that has that key, that is,
選択的サフィックスで接尾辞キーを重複するアプリケーションに遭遇し、この矛盾について追加の処理を実行したくないアプリケーションは、そのキーを持つ最初のサフィックス、つまり、つまり、
2022-07-08T00:14:07Z[u-ca=chinese][u-ca=japanese]
2022-07-08T00:14:07Z[u-ca=chinese]
are then treated the same.
その後、同じように扱われます。
An [RFC3339] timestamp can contain a time-offset value that indicates the offset between local time and UTC (see Section 4 of [RFC3339], noting that Section 2 of the present specification updates Section 4.3 of [RFC3339]).
[RFC3339]タイムスタンプには、現地時間とUTCの間のオフセットを示すタイムオフセット値を含めることができます（[RFC3339]のセクション4を参照してください。
The information given in such a time-offset value can be inconsistent with the information provided in a time zone suffix for an IXDTF timestamp.
このようなタイムオフセット値で指定された情報は、IXDTFタイムスタンプのタイムゾーン接尾辞に提供される情報と矛盾する可能性があります。
For example, a calendar application could store an IXDTF string representing a far-future meeting in a particular time zone. If that time zone's definition is subsequently changed to abolish daylight saving time, IXDTF strings that were originally consistent may now be inconsistent.
たとえば、カレンダーアプリケーションは、特定のタイムゾーンでの遠い会議を表すIXDTF文字列を保存できます。そのタイムゾーンの定義がその後変更されて夏時間を廃止するように変更された場合、元々一貫性があったIXDTF文字列は今一貫していない可能性があります。
In case of an inconsistency between time-offset and time zone suffix, if the critical flag is used on the time zone suffix, an application MUST act on the inconsistency. If the critical flag is not used, it MAY act on the inconsistency. Acting on the inconsistency may involve rejecting the timestamp or resolving the inconsistency via additional information, such as user input and/or programmed behavior.
タイムオフセットとタイムゾーンの接尾辞の間に矛盾がある場合、タイムゾーンの接尾辞で批判的なフラグが使用されている場合、アプリケーションは矛盾に基づいて行動する必要があります。批判的なフラグが使用されない場合、矛盾に基づいて作用する可能性があります。矛盾に基づいて行動するには、タイムスタンプを拒否したり、ユーザー入力やプログラムされた動作などの追加情報を介して矛盾を解決することが含まれます。
For example, the IXDTF timestamps in Figure 1 represent 00:14:07 UTC, indicating a local time with a time-offset of +00:00. However, because Europe/London used offset +01:00 in July 2022, the timestamps are inconsistent, where the first case is one for which the application MUST act on the inconsistency (the time zone suffix is marked critical) and the second case is one for which it MAY act on the inconsistency (the time zone suffix is elective).
たとえば、図1のIXDTFタイムスタンプは00:14:07 UTCを表しており、タイムオフセットが+00：00の現地時間を示しています。ただし、ヨーロッパ/ロンドンは2022年7月にオフセット+01：00を使用したため、タイムスタンプは一貫性がありません。最初のケースは、アプリケーションが矛盾に基づいて行動する必要がある場合（タイムゾーンの接尾辞は重要である）、2番目のケースは次のとおりです。矛盾に基づいて作用する可能性があります（タイムゾーンの接尾辞は選択的です）。
2022-07-08T00:14:07+00:00[!Europe/London]
2022-07-08T00:14:07+00:00[Europe/London]
Figure 1: Inconsistent IXDTF Timestamps
図1：一貫性のないIXDTFタイムスタンプ
As per Section 4.3 of [RFC3339] as updated by Section 2, IXDTF timestamps may also forego indicating local time information in their [RFC3339] part by using Z instead of a numeric time zone offset. The IXDTF timestamps in Figure 2 (which represent the same instant in time as the strings in Figure 1) are not inconsistent because they do not assert any particular local time nor local offset in their [RFC3339] part. Instead, applications that receive these strings can calculate the local offset and local time using the rules of the time zone suffix, such as Europe/London in the example in Figure 2, which like Figure 1 has a case with a time zone suffix marked critical (i.e., the intention is that the application must understand the time zone information) and one marked elective, which then only is provided as additional information.
セクション2で更新された[RFC3339]のセクション4.3によると、IXDTFタイムスタンプは、数値ゾーンオフセットの代わりにzを使用して[RFC3339]の部分のローカル時間情報を示すことも控えている場合があります。図2のIXDTFタイムスタンプ（図1の文字列と同じ瞬間を表す）は、[RFC3339]部分の特定の現地時間やローカルオフセットを主張しないため、一貫性がありません。代わりに、これらの文字列を受信するアプリケーションは、図2の例ではヨーロッパ/ロンドンなどのタイムゾーン接尾辞のルールを使用してローカルオフセットとローカルタイムを計算できます。（つまり、意図は、アプリケーションがタイムゾーン情報を理解しなければならないということです）とマークされた選択科目は、追加情報としてのみ提供されます。
2022-07-08T00:14:07Z[!Europe/London]
2022-07-08T00:14:07Z[Europe/London]
Figure 2: No Inconsistency in IXDTF Timestamps
図2：IXDTFタイムスタンプで矛盾はありません
Note that -00:00 may be used instead of Z because they have the same meaning according to Section 2, but -00:00 is not allowed by [ISO8601:2000] and later so Z is preferred.
-00：00はZの代わりに使用できることに注意してください。セクション2によると同じ意味があるため、[ISO8601：2000]では-00：00は許可されていないため、Zが優先されることに注意してください。
The following rules extend the ABNF syntax defined in [RFC3339] in order to allow the inclusion of an optional suffix.
次のルールは、オプションのサフィックスを含めることを可能にするために、[RFC3339]で定義されているABNF構文を拡張します。
The Internet Extended Date/Time Format (IXDTF) is described by the rule date-time-ext.
インターネット拡張日付/時刻形式（IXDTF）は、ルールの日付時刻端によって説明されています。
date-time and time-numoffset are imported from Section 5.6 of [RFC3339], and ALPHA and DIGIT are imported from Appendix B.1 of [RFC5234].
日付と時刻と時間ノフセットは[RFC3339]のセクション5.6からインポートされ、アルファと数字は[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
Figure 3: ABNF Grammar of Extensions to RFC 3339
図3：RFC 3339への拡張のABNF文法
Note that a time-zone is syntactically similar to a suffix-tag but does not include an equals sign. This special case is only available for time zone tags.
タイムゾーンはサフィックスタグに構文的に類似しているが、等しい記号は含まれていないことに注意してください。この特別なケースは、タイムゾーンタグでのみ使用できます。
The ABNF definition of time-zone-part matches "." and "..", which are both explicitly excluded (see the note below on time-zone-part).
タイムゾーンパートマッチのABNF定義「」。と「..」はどちらも明示的に除外されています（Time-Zone-Partの以下のメモを参照）。
time-zone-name is intended to be the name of an IANA Time Zone. As a generator and a recipient may be using different revisions of the Time Zone Database, recipients may not be aware of such an IANA Time Zone name and should treat such a situation as any other inconsistency.
Time-Zone-Nameは、IANAタイムゾーンの名前であることを目的としています。ジェネレーターと受信者がタイムゾーンデータベースの異なる改訂を使用している可能性があるため、受信者はそのようなIANAタイムゾーン名を認識していない可能性があり、そのような状況を他の矛盾と扱う必要があります。
Note: At the time of writing, the length of each time-zone-part is limited to a maximum of 14 characters by the rules in [TZDB-NAMING]. One platform is known to enforce this limit, and a time zone name on another platform is known to exceed this limit. As the time-zone-name will ultimately have to be looked up in the local database, which therefore has control over the length, the time-zone-part production in Figure 3 is deliberately permissive.
注：執筆時点では、各タイムゾーンパートの長さは、[TZDBネーミング]のルールにより、最大14文字に制限されています。あるプラットフォームはこの制限を強制することが知られており、別のプラットフォームのタイムゾーン名がこの制限を超えることが知られています。タイムゾーン名は最終的にローカルデータベースで調べる必要があるため、長さを制御するため、図3のタイムゾーンパートの生産は意図的に許容されます。
This section contains some examples of Internet Extended Date/Time Format (IXDTF).
このセクションには、インターネット拡張日付/時刻形式（IXDTF）の例がいくつか含まれています。
1996-12-19T16:39:57-08:00
Figure 4: RFC 3339 date-time with Time Zone Offset
図4：RFC 3339タイムゾーンオフセット付きの日付時間
Figure 4 represents 39 minutes and 57 seconds after the 16th hour of December 19, 1996, with an offset of -08:00 from UTC. Note that this is the same instant in time as 1996-12-20T00:39:57Z, expressed in UTC.
図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]
Figure 5: Adding a Time Zone Name
図5：タイムゾーン名の追加
Figure 5 represents the exact same instant in time as the previous example but additionally specifies the human time zone associated with it ("Pacific Time") for time-zone-aware applications to take into account.
図5は、前の例とまったく同じ瞬間を表していますが、時刻ゾーン対応アプリケーションの場合に関連付けられたヒューマンタイムゾーン（「太平洋時間」）をさらに考慮して指定しています。
1996-12-19T16:39:57-08:00[America/Los_Angeles][u-ca=hebrew]
Figure 6: Projecting to the Hebrew Calendar
図6：ヘブライ人カレンダーへの投影
Figure 6 represents the exact same instant in time, but it informs calendar-aware applications (see Section 5) that they should project it to the Hebrew calendar.
図6は、まったく同じ瞬間を表していますが、カレンダーを認識しているアプリケーション（セクション5を参照）に、ヘブライカレンダーに投影する必要があることを通知します。
1996-12-19T16:39:57-08:00[_foo=bar][_baz=bat]
Figure 7: Adding Experimental Tags
図7：実験タグの追加
Figure 7, based on Figure 4, utilizes keys identified as experimental by a leading underscore to declare two additional pieces of information in the suffix; these can be interpreted by implementations that take part in the controlled experiment making use of these tag keys.
図4に基づく図7は、リーディングエルダースコアによって実験的であると識別されたキーを使用して、接尾辞に2つの追加情報を宣言します。これらは、これらのタグキーを使用して制御された実験に参加する実装によって解釈できます。
Out of the possible suffix keys, the suffix key u-ca is allocated to indicate the calendar in which the date/time is preferably presented.
可能なサフィックスキーのうち、接尾辞キーU-CAは、日付/時刻が望ましいカレンダーを示すように割り当てられます。
A calendar is a set of rules defining how dates are counted and consumed by implementations. The set of suffix values allowed for this suffix key is the set of values defined for the Unicode Calendar Identifier [TR35]. [CLDR-LINKS] provides links to the most recent information about [CLDR], both stable and specific development stages.
カレンダーは、実装によって日付がカウントされ、消費される方法を定義する一連のルールです。この接尾辞キーに許可されているサフィックス値のセットは、Unicodeカレンダー識別子[TR35]に対して定義された値のセットです。[CLDR-Links]は、安定した開発段階と特定の開発段階の両方である[CLDR]に関する最新の情報へのリンクを提供します。
IANA has created a registry called "Timestamp Suffix Tag Keys" in a new registry group titled "Internet Date/Time Format". Each entry in the registry shall consist of the information described in Section 3.2. The initial contents of the registry are specified in Table 1.
IANAは、「Internet Date/Time Format」というタイトルの新しいレジストリグループに「Timestampサフィックスタグキー」と呼ばれるレジストリを作成しました。レジストリ内の各エントリは、セクション3.2で説明されている情報で構成されます。レジストリの初期内容を表1に指定します。
+============+==============+==============+============+=========+
| Key | Registration | Description | Change |Reference|
| Identifier | Status | | Controller | |
+============+==============+==============+============+=========+
| u-ca | Permanent | Preferred | IETF |Section 5|
| | | Calendar for | |of RFC |
| | | Presentation | |9557 |
+------------+--------------+--------------+------------+---------+
Table 1: Initial Contents of Timestamp Suffix Tag Keys Registry
表1：タイムスタンプサフィックスタグキーレジストリの初期内容
The registration policy [BCP26] is "Specification Required" for permanent entries and "Expert Review" for provisional ones. In the second case, the experts are instructed to ascertain that a basic specification does exist, even if not complete or published yet.
登録ポリシー[BCP26]は、恒久的なエントリに「必要な仕様」と暫定的なエントリの「専門家のレビュー」です。2番目のケースでは、専門家は、まだ完了または公開されていなくても、基本的な仕様が存在することを確認するように指示されています。
The experts are also instructed to be frugal in the allocation of key identifiers that are suggestive of generally applicable semantics, keeping them in reserve for suffix keys that are likely to enjoy wide use and can make good use of the key identifier's conciseness. If the experts become aware of key identifiers that are deployed and in use, they may also initiate a registration on their own if they deem such a registration can avert potential future collisions.
また、専門家は、一般的に適用可能なセマンティクスを示唆する主要な識別子の割り当てに満足のいくものであるように指示され、幅広い使用を享受する可能性が高く、キー識別子の簡潔さをうまく利用できる接尾辞キーを確保します。専門家が展開され、使用中の主要な識別子に気付いた場合、そのような登録が潜在的な将来の衝突を回避できると判断した場合、独自に登録を開始することもあります。
The ability to include various pieces of ancillary information with a timestamp might lead to excessive disclosure. An example for possibly excessive disclosure is given in Section 7 of [RFC3339]. Similarly, divulging information about the calendar system or the language of choice may provide more information about the originator of a timestamp than the data minimization principle would permit [DATA-MINIMIZATION]. More generally speaking, generators of IXDTF timestamps need to consider whether information to be added to the timestamp is appropriate to divulge to the recipients of this information and need to err on the side of minimizing such disclosure if the set of recipients is not under control of the originator.
タイムスタンプにさまざまな補助情報を含める能力は、過度の開示につながる可能性があります。おそらく過度の開示の例は、[RFC3339]のセクション7に記載されています。同様に、カレンダーシステムまたは選択した言語に関する情報を明かす情報は、データの最小化の原則が許可するよりも、タイムスタンプの発信者に関するより多くの情報を提供する場合があります[データ最小化]。より一般的に言えば、IXDTFタイムスタンプのジェネレーターは、タイムスタンプに追加する情報がこの情報の受信者に漏れるのに適しているかどうかを検討する必要があり、受信者のセットが制御されていない場合、そのような開示を最小限に抑える側で誤りを犯す必要があります。オリジネーター。
As usual when extending the syntax of a data format, this can lead to new vulnerabilities in implementations parsing and processing the format. No considerations are known for the IXDTF syntax that would pose concerns that are out of the ordinary.
通常どおり、データ形式の構文を拡張すると、形式の解析と処理の実装の新しい脆弱性につながる可能性があります。IXDTFの構文については、普通の懸念をもたらすことは知られていません。
Information provided in the various parts of an IXDTF string may be inconsistent in interesting ways, both with the extensions defined in this specification (for instance, see Section 3.4) and with future extensions still to be defined. Where consistent interpretation between multiple actors is required for security purposes (e.g., where timestamps are embedded as parameters in access control information), only extensions that have a well-understood and shared resolution of such inconsistent data can be employed.
IXDTF文字列のさまざまな部分で提供される情報は、この仕様（たとえば、セクション3.4を参照）で定義されている拡張機能と、まだ定義されている将来の拡張機能の両方で、興味深い方法で一貫性がない場合があります。セキュリティ目的で複数のアクター間の一貫した解釈が必要な場合（たとえば、タイムスタンプがアクセス制御情報のパラメーターとして埋め込まれている場合）、そのような一貫性のないデータの十分に理解され共有された解像度を持つ拡張機能のみを使用できます。
[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>.
[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>.
This specification benefits from work prepared by ECMA TC39, specifically in the Temporal proposal.
この仕様は、特に時間的提案でECMA TC39によって作成された作業の恩恵を受けます。
Richard Gibson and Justin Grant provided editorial improvements. The SEDATE WG Chairs Mark McFadden and Bron Gondwana, the latter also in his role as CALEXT WG Chair, helped set up the structures needed to navigate the multi-SDO environment. John Klensin critically accompanied the development of this specification, which led to significant improvements. The authors would also like to especially thank Francesca Palombini for her AD review and for her overall guidance during the development process.
リチャード・ギブソンとジャスティン・グラントは編集上の改善を提供しました。鎮静型のWG椅子は、McFaddenとBron GondwanaのMark Calext WGチェアとしての彼の役割において、マルチSDO環境をナビゲートするために必要な構造のセットアップを支援しました。ジョン・クレンシンは、この仕様の開発に批判的に伴い、それが大幅に改善されました。著者はまた、特にFrancesca Palombiniの広告レビューと、開発プロセス中の全体的なガイダンスについて感謝したいと思います。
Justin Grant
Email: justingrant.ietf.public@gmail.com
Ujjwal Sharma
Igalia, S.L.
Bugallal Marchesi, 22, 1º
15008 A Coruña
Spain
Email: ryzokuken@igalia.com
Carsten Bormann
Universität Bremen TZI
Postfach 330440
D-28359 Bremen
Germany
Phone: +49-421-218-63921
Email: cabo@tzi.org