[要約] RFC 3339は、インターネット上での日付と時刻の表記方法を定義しています。この規格の目的は、タイムスタンプの一貫性と相互運用性を確保することです。
Network Working Group G. Klyne
Request for Comments: 3339 Clearswift Corporation
Category: Standards Track C. Newman
Sun Microsystems
July 2002
Date and Time on the Internet: Timestamps
インターネット上の日付と時刻：タイムスタンプ
Status of this Memo
本文書の状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright（C）The Internet Society（2002）。全著作権所有。
Abstract
概要
This document defines a date and time format for use in Internet protocols that is a profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
このドキュメントでは、グレゴリオ暦を使用して日付と時刻を表すためのISO 8601標準のプロファイルである、インターネットプロトコルで使用する日付と時刻の形式を定義します。
Table of Contents
目次
1. Introduction ............................................ 2
2. Definitions ............................................. 3
3. Two Digit Years ......................................... 4
4. Local Time .............................................. 4
4.1. Coordinated Universal Time (UTC) ...................... 4
4.2. Local Offsets ......................................... 5
4.3. Unknown Local Offset Convention ....................... 5
4.4. Unqualified Local Time ................................ 5
5. Date and Time format .................................... 6
5.1. Ordering .............................................. 6
5.2. Human Readability ..................................... 6
5.3. Rarely Used Options ................................... 7
5.4. Redundant Information ................................. 7
5.5. Simplicity ............................................ 7
5.6. Internet Date/Time Format ............................. 8
5.7. Restrictions .......................................... 9
5.8. Examples ............................................. 10
6. References ............................................. 10
7. Security Considerations ................................ 11
Appendix A. ISO 8601 Collected ABNF ....................... 12
Appendix B. Day of the Week ............................... 14
Appendix C. Leap Years .................................... 14
Appendix D. Leap Seconds ..............................,... 15
Acknowledgements .......................................... 17
Authors' Addresses ........................................ 17
Full Copyright Statement .................................. 18
Date and time formats cause a lot of confusion and interoperability problems on the Internet. This document addresses many of the problems encountered and makes recommendations to improve consistency and interoperability when representing and using date and time in Internet protocols.
日付と時刻の形式は、インターネットで多くの混乱と相互運用性の問題を引き起こします。このドキュメントでは、発生した問題の多くに対処し、インターネットプロトコルで日付と時刻を表現および使用する際の一貫性と相互運用性を向上させるための推奨事項を示します。
This document includes an Internet profile of the ISO 8601 [ISO8601] standard for representation of dates and times using the Gregorian calendar.
このドキュメントには、グレゴリオ暦を使用して日付と時刻を表すためのISO 8601 [ISO8601]標準のインターネットプロファイルが含まれています。
There are many ways in which date and time values might appear in Internet protocols: this document focuses on just one common usage, viz. timestamps for Internet protocol events. This limited consideration has the following consequences:
インターネットプロトコルで日付と時刻の値が表示される方法は多数あります。このドキュメントでは、1つの一般的な使用法、つまり、インターネットプロトコルイベントのタイムスタンプ。この限定的な考慮事項には、次のような影響があります。
o All dates and times are assumed to be in the "current era", somewhere between 0000AD and 9999AD.
o すべての日付と時刻は、「現在の時代」（0000ADから9999ADの間）にあると見なされます。
o All times expressed have a stated relationship (offset) to Coordinated Universal Time (UTC). (This is distinct from some usage in scheduling applications where a local time and location may be known, but the actual relationship to UTC may be dependent on the unknown or unknowable actions of politicians or administrators. The UTC time corresponding to 17:00 on 23rd March 2005 in New York may depend on administrative decisions about daylight savings time. This specification steers well clear of such considerations.)
o 表現されるすべての時間には、協定世界時（UTC）との関係（オフセット）が明記されています。 （これは、現地時間と場所がわかっている可能性があるスケジューリングアプリケーションの一部の使用法とは異なりますが、UTCとの実際の関係は、政治家または管理者の不明または認識できないアクションに依存する場合があります。23時の17:00に対応するUTC時間2005年3月、ニューヨークでは、夏時間に関する管理上の決定に依存する可能性があります。この仕様では、このような考慮事項を十分に回避しています。）
o Timestamps can express times that occurred before the introduction of UTC. Such timestamps are expressed relative to universal time, using the best available practice at the stated time.
o タイムスタンプは、UTCの導入前に発生した時間を表すことができます。このようなタイムスタンプは、指定された時刻に可能な限りのベストプラクティスを使用して、世界時と比較して表されます。
o Date and time expressions indicate an instant in time. Description of time periods, or intervals, is not covered here.
o 日付と時刻の式は、瞬時を示します。期間または間隔の説明はここでは扱いません。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [RFC2119]で説明されているように解釈されます。
UTC Coordinated Universal Time as maintained by the Bureau International des Poids et Mesures (BIPM).
国際ウエイト・アンド・メジャーズ局（BIPM）が維持するUTC協定世界時。
second A basic unit of measurement of time in the International System of Units. It is defined as the duration of 9,192,631,770 cycles of microwave light absorbed or emitted by the hyperfine transition of cesium-133 atoms in their ground state undisturbed by external fields.
2番目の国際単位系における時間の測定の基本単位。それは、外部電場によって妨害されない基底状態のセシウム133原子の超微細遷移によって吸収または放出されるマイクロ波光の9,192,631,770サイクルの継続時間として定義されます。
minute A period of time of 60 seconds. However, see also the restrictions in section 5.7 and Appendix D for how leap seconds are denoted within minutes.
分60秒の期間。ただし、うるう秒が分単位でどのように示されるかについては、セクション5.7および付録Dの制限も参照してください。
hour A period of time of 60 minutes.
時間60分の期間。
day A period of time of 24 hours.
日24時間の期間。
leap year In the Gregorian calendar, a year which has 366 days. A leap year is a year whose number is divisible by four an integral number of times, except that if it is a centennial year (i.e. divisible by one hundred) it shall also be divisible by four hundred an integral number of times.
うるう年グレゴリオ暦では、366日の年。うるう年は、その数が4で割り切れる年です。ただし、それが100年の年（つまり、100で割り切れる年）である場合は、整数で400で割り切れる必要があります。
ABNF Augmented Backus-Naur Form, a format used to represent permissible strings in a protocol or language, as defined in [ABNF].
[ABNF]で定義されているように、プロトコルまたは言語で許可される文字列を表すために使用されるフォーマットであるABNF拡張バッカスナウアフォーム。
Email Date/Time Format The date/time format used by Internet Mail as defined by RFC 2822 [IMAIL-UPDATE].
電子メールの日付/時刻形式RFC 2822 [IMAIL-UPDATE]で定義されている、インターネットメールで使用される日付/時刻形式。
Internet Date/Time Format The date format defined in section 5 of this document.
インターネットの日付/時刻形式このドキュメントのセクション5で定義されている日付形式。
Timestamp This term is used in this document to refer to an unambiguous representation of some instant in time.
タイムスタンプこの用語は、このドキュメントでは、ある時点の明確な表現を指すために使用されます。
Z A suffix which, when applied to a time, denotes a UTC offset of 00:00; often spoken "Zulu" from the ICAO phonetic alphabet representation of the letter "Z".
Z時間に適用される場合、00：00のUTCオフセットを示すサフィックス。文字「Z」のICAO音声アルファベット表現から「ズールー」がよく話されます。
For more information about time scales, see Appendix E of [NTP], Section 3 of [ISO8601], and the appropriate ITU documents [ITU-R-TF].
時間スケールの詳細については、[NTP]の付録E、[ISO8601]のセクション3、および適切なITUドキュメント[ITU-R-TF]を参照してください。
The following requirements are to address the problems of ambiguity of 2-digit years:
次の要件は、2桁の年のあいまいさの問題に対処するためのものです。
o Internet Protocols MUST generate four digit years in dates.
o インターネットプロトコルは、日付に4桁の年を生成する必要があります。
o The use of 2-digit years is deprecated. If a 2-digit year is received, it should be accepted ONLY if an incorrect interpretation will not cause a protocol or processing failure (e.g. if used only for logging or tracing purposes).
o 2桁の年の使用は非推奨です。 2桁の年を受け取った場合、それは、誤った解釈がプロトコルや処理の失敗を引き起こさない場合にのみ受け入れられる必要があります（たとえば、ロギングまたはトレースの目的でのみ使用される場合）。
o It is possible that a program using two digit years will represent years after 1999 as three digits. This occurs if the program simply subtracts 1900 from the year and doesn't check the number of digits. Programs wishing to robustly deal with dates generated by such broken software may add 1900 to three digit years.
o 2桁の年を使用するプログラムは、1999年以降の年を3桁で表す可能性があります。これは、プログラムが単に年から1900を減算し、桁数をチェックしない場合に発生します。そのような壊れたソフトウェアによって生成された日付をしっかりと処理したいプログラムは、3桁の年に1900を加えるかもしれません。
o It is possible that a program using two digit years will represent years after 1999 as ":0", ":1", ... ":9", ";0", ... This occurs if the program simply subtracts 1900 from the year and adds the decade to the US-ASCII character zero. Programs wishing to robustly deal with dates generated by such broken software should detect non-numeric decades and interpret appropriately.
o 2桁の年を使用するプログラムは、1999年より後の年を "：0"、 "：1"、... "：9"、 "; 0"、...として表す可能性があります。これは、プログラムが単に1900を減算する場合に発生します。年から10年をUS-ASCII文字ゼロに追加します。このような壊れたソフトウェアによって生成された日付を確実に処理することを望むプログラムは、非数値の数十年を検出し、適切に解釈する必要があります。
The problems with two digit years amply demonstrate why all dates and times used in Internet protocols MUST be fully qualified.
2桁の年に関する問題は、インターネットプロトコルで使用されるすべての日付と時刻が完全に修飾されている必要がある理由を十分に示しています。
Because the daylight saving rules for local time zones are so convoluted and can change based on local law at unpredictable times, true interoperability is best achieved by using Coordinated Universal Time (UTC). This specification does not cater to local time zone rules.
ローカルタイムゾーンの夏時間規則は非常に複雑で、予測できない時間に現地の法律に基づいて変更される可能性があるため、協定世界時（UTC）を使用することにより、真の相互運用性を実現できます。この仕様は、ローカルタイムゾーンルールに対応していません。
The offset between local time and UTC is often useful information. For example, in electronic mail (RFC2822, [IMAIL-UPDATE]) the local offset provides a useful heuristic to determine the probability of a prompt response. Attempts to label local offsets with alphabetic strings have resulted in poor interoperability in the past [IMAIL], [HOST-REQ]. As a result, RFC2822 [IMAIL-UPDATE] has made numeric offsets mandatory.
多くの場合、現地時間とUTCの間のオフセットは有用な情報です。たとえば、電子メール（RFC2822、[IMAIL-UPDATE]）では、ローカルオフセットは、迅速な応答の確率を判断するための有用なヒューリスティックを提供します。過去の[IMAIL]、[HOST-REQ]では、ローカルオフセットにアルファベット文字列でラベルを付けようとしたため、相互運用性が低下していました。その結果、RFC2822 [IMAIL-UPDATE]により、数値オフセットが必須になりました。
Numeric offsets are calculated as "local time minus UTC". So the equivalent time in UTC can be determined by subtracting the offset from the local time. For example, 18:50:00-04:00 is the same time as 22:50:00Z. (This example shows negative offsets handled by adding the absolute value of the offset.)
数値オフセットは、「現地時間からUTCを引いた値」として計算されます。したがって、現地時間からオフセットを差し引くことで、UTCでの同等の時間を決定できます。たとえば、18：50：00-04：00は22：50：00Zと同じ時間です。 （この例は、オフセットの絶対値を追加することによって処理される負のオフセットを示しています。）
NOTE: Following ISO 8601, numeric offsets represent only time zones that differ from UTC by an integral number of minutes. However, many historical time zones differ from UTC by a non-integral number of minutes. To represent such historical time stamps exactly, applications must convert them to a representable time zone.
注：ISO 8601に従って、数値のオフセットはUTCと整数分の分だけ異なるタイムゾーンのみを表します。ただし、多くの過去のタイムゾーンは、整数でない分数だけUTCと異なります。このような履歴タイムスタンプを正確に表すには、アプリケーションでそれらを表現可能なタイムゾーンに変換する必要があります。
If the time in UTC is known, but the offset to local time is unknown, this can be represented with an offset of "-00:00". This differs semantically from an offset of "Z" or "+00:00", which imply that UTC is the preferred reference point for the specified time. RFC2822 [IMAIL-UPDATE] describes a similar convention for email.
UTCでの時刻はわかっているが、現地時間へのオフセットが不明である場合、これは「-00：00」のオフセットで表すことができます。これは、「Z」または「+00：00」のオフセットと意味的に異なります。これは、UTCが指定された時間の優先参照ポイントであることを意味します。 RFC2822 [IMAIL-UPDATE]には、電子メールの同様の規則が記述されています。
A number of devices currently connected to the Internet run their internal clocks in local time and are unaware of UTC. While the Internet does have a tradition of accepting reality when creating specifications, this should not be done at the expense of interoperability. Since interpretation of an unqualified local time zone will fail in approximately 23/24 of the globe, the interoperability problems of unqualified local time are deemed unacceptable for the Internet. Systems that are configured with a local time, are unaware of the corresponding UTC offset, and depend on time synchronization with other Internet systems, MUST use a mechanism that ensures correct synchronization with UTC. Some suitable mechanisms are:
現在インターネットに接続されている多くのデバイスは、ローカルクロックで内部クロックを実行しており、UTCを認識していません。インターネットには仕様を作成するときに現実を受け入れるという伝統がありますが、相互運用性を犠牲にしてこれを行うべきではありません。修飾されていないローカルタイムゾーンの解釈は世界の約23/24で失敗するため、修飾されていないローカル時間の相互運用性の問題は、インターネットでは受け入れられないと見なされます。ローカル時刻で構成され、対応するUTCオフセットを認識せず、他のインターネットシステムとの時刻同期に依存するシステムは、UTCとの正しい同期を保証するメカニズムを使用する必要があります。いくつかの適切なメカニズムは次のとおりです。
o Use Network Time Protocol [NTP] to obtain the time in UTC.
o ネットワークタイムプロトコル[NTP]を使用して、UTCで時刻を取得します。
o Use another host in the same local time zone as a gateway to the Internet. This host MUST correct unqualified local times that are transmitted to other hosts.
o インターネットへのゲートウェイとして同じローカルタイムゾーンの別のホストを使用します。このホストは、他のホストに送信される修飾されていない現地時間を修正する必要があります。
o Prompt the user for the local time zone and daylight saving rule settings.
o ローカルタイムゾーンと夏時間規則の設定をユーザーに要求します。
This section discusses desirable qualities of date and time formats and defines a profile of ISO 8601 for use in Internet protocols.
このセクションでは、日付と時刻の形式の望ましい品質について説明し、インターネットプロトコルで使用するためのISO 8601のプロファイルを定義します。
If date and time components are ordered from least precise to most precise, then a useful property is achieved. Assuming that the time zones of the dates and times are the same (e.g., all in UTC), expressed using the same string (e.g., all "Z" or all "+00:00"), and all times have the same number of fractional second digits, then the date and time strings may be sorted as strings (e.g., using the strcmp() function in C) and a time-ordered sequence will result. The presence of optional punctuation would violate this characteristic.
日付と時刻のコンポーネントが最も精度の低いものから最も精度の高いものの順に並べられている場合、有用なプロパティが得られます。日付と時刻のタイムゾーンは同じで（たとえば、すべてUTCで）、同じ文字列を使用して表現され（たとえば、すべて「Z」またはすべて「+00：00」）、すべての時刻が同じ番号であると仮定します。小数秒の場合、日付と時刻の文字列は文字列として（たとえば、Cのstrcmp()関数を使用して）ソートされ、時間順のシーケンスが生成されます。オプションの句読点があると、この特性に違反します。
Human readability has proved to be a valuable feature of Internet protocols. Human readable protocols greatly reduce the costs of debugging since telnet often suffices as a test client and network analyzers need not be modified with knowledge of the protocol. On the other hand, human readability sometimes results in interoperability problems. For example, the date format "10/11/1996" is completely unsuitable for global interchange because it is interpreted differently in different countries. In addition, the date format in [IMAIL] has resulted in interoperability problems when people assumed any text string was permitted and translated the three letter abbreviations to other languages or substituted date formats which were easier to generate (e.g. the format used by the C function ctime). For this reason, a balance must be struck between human readability and interoperability.
人間の可読性は、インターネットプロトコルの貴重な機能であることが証明されています。人間が読めるプロトコルは、テストのクライアントとしてTelnetで十分であり、ネットワークアナライザをプロトコルの知識で変更する必要がないため、デバッグのコストを大幅に削減します。一方、人間が読みやすくすると、相互運用性の問題が発生することがあります。たとえば、日付形式「1996年10月11日」は、国によって解釈が異なるため、グローバル交換にはまったく適していません。さらに、[IMAIL]の日付形式は、テキスト文字列が許可されていると想定し、3文字の省略形を他の言語または生成しやすい日付形式（例：C関数で使用される形式）に変換した場合に相互運用性の問題を引き起こしましたctime）。このため、人間の可読性と相互運用性のバランスをとる必要があります。
Because no date and time format is readable according to the conventions of all countries, Internet clients SHOULD be prepared to transform dates into a display format suitable for the locality. This may include translating UTC to local time.
すべての国の規則に従って日付と時刻の形式を読み取ることができないため、インターネットクライアントは、日付を地域に適した表示形式に変換する準備をする必要があります。これには、UTCを現地時間に変換することが含まれます。
A format which includes rarely used options is likely to cause interoperability problems. This is because rarely used options are less likely to be used in alpha or beta testing, so bugs in parsing are less likely to be discovered. Rarely used options should be made mandatory or omitted for the sake of interoperability whenever possible.
ほとんど使用されないオプションを含む形式は、相互運用性の問題を引き起こす可能性があります。これは、めったに使用されないオプションがアルファまたはベータテストで使用される可能性が低いため、解析のバグが発見される可能性が低いためです。相互運用性を確保するために、使用頻度の低いオプションは可能な限り必須にするか省略してください。
The format defined below includes only one rarely used option: fractions of a second. It is expected that this will be used only by applications which require strict ordering of date/time stamps or which have an unusual precision requirement.
以下に定義するフォーマットには、めったに使用されないオプションが1つだけ含まれています。これは、日付/時刻スタンプの厳密な順序付けが必要なアプリケーション、または異常な精度要件があるアプリケーションでのみ使用されることが予想されます。
If a date/time format includes redundant information, that introduces the possibility that the redundant information will not correlate. For example, including the day of the week in a date/time format introduces the possibility that the day of week is incorrect but the date is correct, or vice versa. Since it is not difficult to compute the day of week from a date (see Appendix B), the day of week should not be included in a date/time format.
日付/時刻形式に冗長な情報が含まれている場合、冗長な情報が相関しない可能性があります。たとえば、日付/時刻形式で曜日を含めると、曜日は正しくないが日付は正しい、またはその逆の可能性が生じます。日付から曜日を計算することは難しくないので（付録Bを参照）、曜日を日付/時刻形式に含めないでください。
The complete set of date and time formats specified in ISO 8601 [ISO8601] is quite complex in an attempt to provide multiple representations and partial representations. Appendix A contains an attempt to translate the complete syntax of ISO 8601 into ABNF. Internet protocols have somewhat different requirements and simplicity has proved to be an important characteristic. In addition, Internet protocols usually need complete specification of data in order to achieve true interoperability. Therefore, the complete grammar for ISO 8601 is deemed too complex for most Internet protocols.
ISO 8601 [ISO8601]で指定されている日付と時刻の形式の完全なセットは、複数の表現と部分的な表現を提供しようとすると、非常に複雑になります。付録Aには、ISO 8601の完全な構文をABNFに変換する試みが含まれています。インターネットプロトコルには多少異なる要件があり、シンプルさが重要な特性であることが証明されています。さらに、インターネットプロトコルは通常、真の相互運用性を実現するためにデータの完全な仕様を必要とします。したがって、ISO 8601の完全な文法は、ほとんどのインターネットプロトコルにとって複雑すぎると見なされます。
The following section defines a profile of ISO 8601 for use on the Internet. It is a conformant subset of the ISO 8601 extended format. Simplicity is achieved by making most fields and punctuation mandatory.
次のセクションでは、インターネットで使用するためのISO 8601のプロファイルを定義します。これは、ISO 8601拡張フォーマットの準拠サブセットです。ほとんどのフィールドと句読点を必須にすることで、シンプルさが実現します。
The following profile of ISO 8601 [ISO8601] dates SHOULD be used in new protocols on the Internet. This is specified using the syntax description notation defined in [ABNF].
次のISO 8601 [ISO8601]日付のプロファイルは、インターネット上の新しいプロトコルで使用する必要があります（SHOULD）。これは、[ABNF]で定義されている構文記述表記を使用して指定されます。
date-fullyear = 4DIGIT
date-month = 2DIGIT ; 01-12
date-mday = 2DIGIT ; 01-28, 01-29, 01-30, 01-31 based on
; month/year
time-hour = 2DIGIT ; 00-23
time-minute = 2DIGIT ; 00-59
time-second = 2DIGIT ; 00-58, 00-59, 00-60 based on leap second
; rules
time-secfrac = "." 1*DIGIT
time-numoffset = ("+" / "-") time-hour ":" time-minute
time-offset = "Z" / time-numoffset
partial-time = time-hour ":" time-minute ":" time-second [time-secfrac] full-date = date-fullyear "-" date-month "-" date-mday full-time = partial-time time-offset
部分的な時間=時間-時間 "："時間-分 "："時間-秒[time-secfrac]完全な日付=日付-完全に "-"日付-月 "-"日付-mday完全な時間=部分的な時間時間オフセット
date-time = full-date "T" full-time
日時=フルタイム "T"フルタイム
NOTE: Per [ABNF] and ISO8601, the "T" and "Z" characters in this syntax may alternatively be lower case "t" or "z" respectively.
注：[ABNF]およびISO8601に従って、この構文の「T」および「Z」文字は、代わりにそれぞれ小文字の「t」または「z」の場合があります。
This date/time format may be used in some environments or contexts that distinguish between the upper- and lower-case letters 'A'-'Z' and 'a'-'z' (e.g. XML). Specifications that use this format in such environments MAY further limit the date/time syntax so that the letters 'T' and 'Z' used in the date/time syntax must always be upper case. Applications that generate this format SHOULD use upper case letters.
この日付/時刻形式は、大文字と小文字の「A」-「Z」と「a」-「z」を区別する一部の環境またはコンテキストで使用される場合があります（例：XML）。このような環境でこの形式を使用する仕様では、日付/時刻の構文をさらに制限して、日付/時刻の構文で使用される文字「T」および「Z」を常に大文字にする必要があります。この形式を生成するアプリケーションでは、大文字を使用する必要があります（SHOULD）。
NOTE: ISO 8601 defines date and time separated by "T". Applications using this syntax may choose, for the sake of readability, to specify a full-date and full-time separated by (say) a space character.
注：ISO 8601は、「T」で区切られた日付と時刻を定義します。この構文を使用するアプリケーションは、読みやすさのために、（たとえば）スペース文字で区切られたフル日付とフルタイムを指定することを選択できます。
The grammar element date-mday represents the day number within the current month. The maximum value varies based on the month and year as follows:
文法要素date-mdayは、今月の日数を表します。最大値は、月と年によって次のように異なります。
Month Number Month/Year Maximum value of date-mday
------------ ---------- --------------------------
01 January 31
02 February, normal 28
02 February, leap year 29
03 March 31
04 April 30
05 May 31
06 June 30
07 July 31
08 August 31
09 September 30
10 October 31
11 November 30
12 December 31
Appendix C contains sample C code to determine if a year is a leap year.
付録Cには、年がうるう年かどうかを判別するためのサンプルCコードが含まれています。
The grammar element time-second may have the value "60" at the end of months in which a leap second occurs -- to date: June (XXXX-06- 30T23:59:60Z) or December (XXXX-12-31T23:59:60Z); see Appendix D for a table of leap seconds. It is also possible for a leap second to be subtracted, at which times the maximum value of time-second is "58". At all other times the maximum value of time-second is "59". Further, in time zones other than "Z", the leap second point is shifted by the zone offset (so it happens at the same instant around the globe).
文法要素のtime-secondは、うるう秒が発生する月の終わりに値 "60"を持つ場合があります-今日まで：6月（XXXX-06-30T23：59：60Z）または12月（XXXX-12-31T23： 59：60Z）;うるう秒の表については、付録Dを参照してください。うるう秒を減算することもできます。その場合、time-secondの最大値は「58」です。それ以外の場合、time-secondの最大値は「59」です。さらに、「Z」以外のタイムゾーンでは、うるう秒のポイントがゾーンオフセットによってシフトされます（そのため、地球上の同じ瞬間に発生します）。
Leap seconds cannot be predicted far into the future. The International Earth Rotation Service publishes bulletins [IERS] that announce leap seconds with a few weeks' warning. Applications should not generate timestamps involving inserted leap seconds until after the leap seconds are announced.
うるう秒は遠くまで予測できません。国際地球回転サービスは、うるう秒を数週間の警告で通知する速報[IERS]を公開しています。アプリケーションは、うるう秒がアナウンスされるまで、挿入されたうるう秒を含むタイムスタンプを生成しないでください。
Although ISO 8601 permits the hour to be "24", this profile of ISO 8601 only allows values between "00" and "23" for the hour in order to reduce confusion.
ISO 8601では時間を「24」にすることが許可されていますが、ISO 8601のこのプロファイルでは、混乱を減らすために、時間に「00」から「23」までの値のみを許可しています。
Here are some examples of Internet date/time format.
インターネットの日付/時刻形式の例をいくつか示します。
1985-04-12T23:20:50.52Z
1985-04-12T23：20：50.52Z
This represents 20 minutes and 50.52 seconds after the 23rd hour of April 12th, 1985 in UTC.
これは、1985年4月12日23時からUTCで20分50.52秒を表します。
1996-12-19T16:39:57-08:00
This represents 39 minutes and 57 seconds after the 16th hour of December 19th, 1996 with an offset of -08:00 from UTC (Pacific Standard Time). Note that this is equivalent to 1996-12-20T00:39:57Z in UTC.
これは、1996年12月19日の16時間後の39分57秒を表し、UTC（太平洋標準時）から-08：00のオフセットがあります。これはUTCの1996-12-20T00：39：57Zに相当することに注意してください。
1990-12-31T23:59:60Z
1990-12-31A：失う：60 g
This represents the leap second inserted at the end of 1990.
これは、1990年の終わりに挿入されたうるう秒を表します。
1990-12-31T15:59:60-08:00
This represents the same leap second in Pacific Standard Time, 8 hours behind UTC.
これは、太平洋標準時と同じうるう秒であり、UTCより8時間遅れています。
1937-01-01T12:00:27.87+00:20
This represents the same instant of time as noon, January 1, 1937, Netherlands time. Standard time in the Netherlands was exactly 19 minutes and 32.13 seconds ahead of UTC by law from 1909-05-01 through 1937-06-30. This time zone cannot be represented exactly using the HH:MM format, and this timestamp uses the closest representable UTC offset.
これは、オランダの1937年1月1日正午と同じ瞬間を表しています。オランダの標準時は、法律により1909-05-01から1937-06-30までUTCより19分32.13秒進んでいました。このタイムゾーンは、HH：MM形式を使用して正確に表すことはできません。このタイムスタンプは、最も近い表現可能なUTCオフセットを使用します。
[ZELLER] Zeller, C., "Kalender-Formeln", Acta Mathematica, Vol. 9, Nov 1886.
[ZELLER] Zeller、C。、「Calendar Formulas」、Acta Mathematica、Vol。9、1886年11月。
[IMAIL] Crocker, D., "Standard for the Format of Arpa Internet Text Messages", STD 11, RFC 822, August 1982.
[画像] Crocker、D。、「Arpaインターネットテキストメッセージのフォーマットの標準」、STD 11、RFC 822、1982年8月。
[IMAIL-UPDATE] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
[IMAIL-UPDATE] Resnick、P。、「インターネットメッセージ形式」、RFC 2822、2001年4月。
[ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[ABNF] Crocker、D。およびP. Overell、「構文仕様の拡張BNF：ABNF」、RFC 2234、1997年11月。
[ISO8601] "Data elements and interchange formats -- Information interchange -- Representation of dates and times", ISO 8601:1988(E), International Organization for Standardization, June, 1988.
[ISO8601]「データ要素と交換フォーマット-情報交換-日付と時刻の表現」、ISO 8601：1988（E）、国際標準化機構、1988年6月。
[ISO8601:2000] "Data elements and interchange formats -- Information interchange -- Representation of dates and times", ISO 8601:2000, International Organization for Standardization, December, 2000.
[ISO8601：2000]「データ要素と交換フォーマット-情報交換-日付と時刻の表現」、ISO 8601：2000、国際標準化機構、2000年12月。
[HOST-REQ] Braden, R., "Requirements for Internet Hosts -- Application and Support", STD 3, RFC 1123, October 1989.
[HOST-REQ] Braden、R。、「インターネットホストの要件-アプリケーションとサポート」、STD 3、RFC 1123、1989年10月。
[IERS] International Earth Rotation Service Bulletins, <http://hpiers.obspm.fr/eop-pc/products/bulletins.html>.
[IERS]国際地球回転サービス速報、<http://hpiers.obspm.fr/eop-pc/products/bulletins.html>。
[NTP] Mills, D, "Network Time Protocol (Version 3) Specification, Implementation and Analysis", RFC 1305, March 1992.
[NTP] Mills、D、「Network Time Protocol（Version 3）Specification、Implementation and Analysis」、RFC 1305、1992年3月。
[ITU-R-TF] International Telecommunication Union Recommendations
for Time Signals and Frequency Standards Emissions.
<http://www.itu.ch/publications/itu-r/iturtf.htm>
[RFC2119] Bradner, S, "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S、「RFCで使用して要件レベルを示すためのキーワード」、BCP 14、RFC 2119、1997年3月。
Since the local time zone of a site may be useful for determining a time when systems are less likely to be monitored and might be more susceptible to a security probe, some sites may wish to emit times in UTC only. Others might consider this to be loss of useful functionality at the hands of paranoia.
サイトのローカルタイムゾーンは、システムが監視される可能性が低く、セキュリティプローブの影響を受けやすい可能性がある時間を決定するのに役立つため、一部のサイトではUTCのみで時刻を出力したい場合があります。他の人はこれをパラノイアの手での有用な機能の喪失であると考えるかもしれません。
This information is based on the 1988 version of ISO 8601. There may be some changes in the 2000 revision.
この情報は、ISO 8601の1988バージョンに基づいています。2000年のリビジョンではいくつかの変更が行われる可能性があります。
ISO 8601 does not specify a formal grammar for the date and time formats it defines. The following is an attempt to create a formal grammar from ISO 8601. This is informational only and may contain errors. ISO 8601 remains the authoritative reference.
ISO 8601は、それが定義する日付と時刻の形式の正式な文法を指定していません。以下は、ISO 8601から正式な文法を作成する試みです。これは情報提供のみを目的としており、エラーが含まれている可能性があります。 ISO 8601は引き続き信頼できる参照です。
Note that due to ambiguities in ISO 8601, some interpretations had to be made. First, ISO 8601 is not clear if mixtures of basic and extended format are permissible. This grammar permits mixtures. ISO 8601 is not clear on whether an hour of 24 is permissible only if minutes and seconds are 0. This assumes that an hour of 24 is permissible in any context. Restrictions on date-mday in section 5.7 apply. ISO 8601 states that the "T" may be omitted under some circumstances. This grammar requires the "T" to avoid ambiguity. ISO 8601 also requires (in section 5.3.1.3) that a decimal fraction be proceeded by a "0" if less than unity. Annex B.2 of ISO 8601 gives examples where the decimal fractions are not preceded by a "0". This grammar assumes section 5.3.1.3 is correct and that Annex B.2 is in error.
ISO 8601にはあいまいさがあるため、いくつかの解釈を行う必要があったことに注意してください。まず、ISO 8601は、基本フォーマットと拡張フォーマットの混合が許容されるかどうか明確ではありません。この文法は混合を許可します。 ISO 8601は、分と秒が0の場合にのみ24時間の1時間が許容されるかどうかについて明確ではありません。これは、24時間の1時間がどのような状況でも許容されると想定しています。セクション5.7のdate-mdayの制限が適用されます。 ISO 8601では、「T」は状況によっては省略される場合があると規定されています。この文法では、あいまいさを避けるために「T」が必要です。 ISO 8601では、（セクション5.3.1.3で）小数点以下が1未満の場合は「0」で始まる必要があります。 ISO 8601の付録B.2は、小数部の前に「0」がない例を示しています。この文法は、セクション5.3.1.3が正しく、Annex B.2に誤りがあることを前提としています。
date-century = 2DIGIT ; 00-99
date-decade = DIGIT ; 0-9
date-subdecade = DIGIT ; 0-9
date-year = date-decade date-subdecade
date-fullyear = date-century date-year
date-month = 2DIGIT ; 01-12
date-wday = DIGIT ; 1-7 ; 1 is Monday, 7 is Sunday
date-mday = 2DIGIT ; 01-28, 01-29, 01-30, 01-31 based on
; month/year
date-yday = 3DIGIT ; 001-365, 001-366 based on year
date-week = 2DIGIT ; 01-52, 01-53 based on year
datepart-fullyear = [date-century] date-year ["-"]
datepart-ptyear = "-" [date-subdecade ["-"]]
datepart-wkyear = datepart-ptyear / datepart-fullyear
dateopt-century = "-" / date-century
dateopt-fullyear = "-" / datepart-fullyear
dateopt-year = "-" / (date-year ["-"])
dateopt-month = "-" / (date-month ["-"])
dateopt-week = "-" / (date-week ["-"])
datespec-full = datepart-fullyear date-month ["-"] date-mday
datespec-year = date-century / dateopt-century date-year
datespec-month = "-" dateopt-year date-month [["-"] date-mday]
datespec-mday = "--" dateopt-month date-mday
datespec-week = datepart-wkyear "W"
(date-week / dateopt-week date-wday)
datespec-wday = "---" date-wday
datespec-yday = dateopt-fullyear date-yday
date = datespec-full / datespec-year
/ datespec-month /
datespec-mday / datespec-week / datespec-wday / datespec-yday
Time:
時間：
time-hour = 2DIGIT ; 00-24
time-minute = 2DIGIT ; 00-59
time-second = 2DIGIT ; 00-58, 00-59, 00-60 based on
; leap-second rules
time-fraction = ("," / ".") 1*DIGIT
time-numoffset = ("+" / "-") time-hour [[":"] time-minute]
time-zone = "Z" / time-numoffset
timeopt-hour = "-" / (time-hour [":"])
timeopt-minute = "-" / (time-minute [":"])
timespec-hour = time-hour [[":"] time-minute [[":"] time-second]]
timespec-minute = timeopt-hour time-minute [[":"] time-second]
timespec-second = "-" timeopt-minute time-second
timespec-base = timespec-hour / timespec-minute / timespec-second
time = timespec-base [time-fraction] [time-zone]
時間= timespec-base [time-fraction] [time-zone]
iso-date-time = date "T" time
iso-date-time =日付 "T"時間
Durations:
期間：
dur-second = 1*DIGIT "S"
dur-minute = 1*DIGIT "M" [dur-second]
dur-hour = 1*DIGIT "H" [dur-minute]
dur-time = "T" (dur-hour / dur-minute / dur-second)
dur-day = 1*DIGIT "D"
dur-week = 1*DIGIT "W"
dur-month = 1*DIGIT "M" [dur-day]
dur-year = 1*DIGIT "Y" [dur-month]
dur-date = (dur-day / dur-month / dur-year) [dur-time]
duration = "P" (dur-date / dur-time / dur-week)
Periods:
期間：
period-explicit = iso-date-time "/" iso-date-time
period-start = iso-date-time "/" duration
period-end = duration "/" iso-date-time
period = period-explicit / period-start / period-end
The following is a sample C subroutine loosely based on Zeller's Congruence [Zeller] which may be used to obtain the day of the week for dates on or after 0000-03-01:
以下は、Zeller's Congruence [Zeller]に大まかに基づいたサンプルCサブルーチンで、0000-03-01以降の日付の曜日を取得するために使用できます。
char *day_of_week(int day, int month, int year)
{
int cent;
char *dayofweek[] = {
"Sunday", "Monday", "Tuesday", "Wednesday",
"Thursday", "Friday", "Saturday"
};
/* adjust months so February is the last one */
month -= 2;
if (month < 1) {
month += 12;
--year;
}
/* split by century */
cent = year / 100;
year %= 100;
return (dayofweek[((26 * month - 2) / 10 + day + year
+ year / 4 + cent / 4 + 5 * cent) % 7]);
}
Here is a sample C subroutine to calculate if a year is a leap year:
以下は、年がうるう年であるかどうかを計算するサンプルCサブルーチンです。
/* This returns non-zero if year is a leap year. Must use 4 digit
year.
*/
int leap_year(int year)
{
return (year % 4 == 0 && (year % 100 != 0 || year % 400 == 0));
}
Information about leap seconds can be found at: <http://tycho.usno.navy.mil/leapsec.html>. In particular, it notes that:
うるう秒に関する情報は、<http://tycho.usno.navy.mil/leapsec.html>にあります。特に、次のように述べています。
The decision to introduce a leap second in UTC is the responsibility of the International Earth Rotation Service (IERS). According to the CCIR Recommendation, first preference is given to the opportunities at the end of December and June, and second preference to those at the end of March and September.
うるう秒をUTCに導入する決定は、国際地球回転サービス（IERS）の責任です。 CCIR勧告によれば、12月末と6月の機会が優先され、3月末と9月の機会が優先されます。
When required, insertion of a leap second occurs as an extra second at the end of a day in UTC, represented by a timestamp of the form YYYY-MM-DDT23:59:60Z. A leap second occurs simultaneously in all time zones, so that time zone relationships are not affected. See section 5.8 for some examples of leap second times.
必要に応じて、うるう秒の挿入は、UTCの1日の終わりに余分な1秒として発生し、YYYY-MM-DDT23：59：60Z形式のタイムスタンプで表されます。うるう秒はすべてのタイムゾーンで同時に発生するため、タイムゾーンの関係は影響を受けません。うるう秒の例については、セクション5.8を参照してください。
The following table is an excerpt from the table maintained by the United States Naval Observatory. The source data is located at:
次の表は、米国海軍天文台が管理している表からの抜粋です。ソースデータは次の場所にあります。
<ftp://maia.usno.navy.mil/ser7/tai-utc.dat>
This table shows the date of the leap second, and the difference between the time standard TAI (which isn't adjusted by leap seconds) and UTC after that leap second.
この表は、うるう秒の日付と、標準の時刻TAI（うるう秒では調整されません）とそのうるう秒後のUTCとの差を示しています。
UTC Date TAI - UTC After Leap Second
-------- ---------------------------
1972-06-30 11
1972-12-31 12
1973-12-31 13
1974-12-31 14
1975-12-31 15
1976-12-31 16
1977-12-31 17
1978-12-31 18
1979-12-31 19
1981-06-30 20
1982-06-30 21
1983-06-30 22
1985-06-30 23
1987-12-31 24
1989-12-31 25
1990-12-31 26
1992-06-30 27
1993-06-30 28
1994-06-30 29
1995-12-31 30
1997-06-30 31
1998-12-31 32
Acknowledgements
謝辞
The following people provided helpful advice for an earlier incarnation of this document: Ned Freed, Neal McBurnett, David Keegel, Markus Kuhn, Paul Eggert and Robert Elz. Thanks are also due to participants of the IETF Calendaring/Scheduling working group mailing list, and participants of the time zone mailing list.
次の人々は、このドキュメントの初期の化身に役立つアドバイスを提供しました：Ned Freed、Neal McBurnett、David Keegel、Markus Kuhn、Paul Eggert、Robert Elz。 IETF Calendaring / Schedulingワーキンググループメーリングリストの参加者、およびタイムゾーンメーリングリストの参加者にも感謝します。
The following reviewers contributed helpful suggestions for the present revision: Tom Harsch, Markus Kuhn, Pete Resnick, Dan Kohn. Paul Eggert provided many careful observations regarding the subtleties of leap seconds and time zone offsets. The following people noted corrections and improvements to earlier drafts: Dr John Stockton, Jutta Degener, Joe Abley, and Dan Wing.
次のレビュアーは、今回の改訂に役立つ提案を提供しました：Tom Harsch、Markus Kuhn、Pete Resnick、Dan Kohn。ポールエガートは、うるう秒の微妙な違いとタイムゾーンオフセットに関して多くの注意深い観察を行いました。次の人々は、以前のドラフトに対する修正と改善に言及しました：ジョンストックトン博士、ジュッタデゲナー、ジョーアブリー、ダンウィング。
Authors' Addresses
著者のアドレス
Chris Newman Sun Microsystems 1050 Lakes Drive, Suite 250 West Covina, CA 91790 USA
Chris Newman Sun Microsystems 1050 Lakes Drive、Suite 250 West Covina、CA 91790 USA
EMail: chris.newman@sun.com
Graham Klyne (editor, this revision) Clearswift Corporation 1310 Waterside Arlington Business Park Theale, Reading RG7 4SA UK
Graham Klyne（編集者、この改訂）Clearswift Corporation 1310 Waterside Arlington Business Park Theale、Reading RG7 4SA UK
Phone: +44 11 8903 8903
Fax: +44 11 8903 9000
EMail: GK@ACM.ORG
Full Copyright Statement
完全な著作権表示
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright（C）The Internet Society（2002）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントとその翻訳はコピーして他のユーザーに提供することができ、コメントまたはその他の方法で説明したり、その実装を支援する二次的著作物は、いかなる種類の制限なしに、全体または一部を準備、コピー、公開、および配布することができます。 、ただし、上記の著作権表示とこの段落は、そのようなすべてのコピーと派生物に含まれています。ただし、このドキュメント自体は、著作権に関する通知を削除したり、インターネットソサエティや他のインターネット組織への参照を削除したりするなど、いかなる方法でも変更できません。ただし、インターネット標準を開発する目的で必要な場合は除きます。インターネット標準のプロセスに従うか、または必要に応じて、それを英語以外の言語に翻訳する必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記で付与された制限付きのアクセス許可は永続的であり、インターネットソサエティまたはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は「現状有姿」で提供され、インターネット社会およびインターネット技術タスクフォースは、明示または黙示を問わず、ここに記載されている情報の使用が保証するものに限定されないいかなる保証も含め、一切の保証を否認します。商品性または特定の目的への適合性に関する権利または黙示の保証を侵害すること。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能への資金提供は、現在Internet Societyから提供されています。