ネットワーク作業部会 G. Klyne
Request for Comments: 3339 Clearswift Corporation
分類: 標準化過程 C. Newman
Sun Microsystems
2002年7月
インターネット上の日付と時刻: タイムスタンプ
このメモの位置付け
本文書は、インターネットコミュニティのためのインターネット標準化
過程プロトコルを規定し、改善に向けた議論と提案を求めるものである。
このプロトコルの標準化状態および位置付けについては、「Internet
Official Protocol Standards」（STD 1）の最新版を参照されたい。
このメモの配布に制限はない。
Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract
本文書は、インターネットプロトコルで使用するための日付および時刻の
形式を定義するものであり、グレゴリオ暦を用いた日付および時刻の表現
に関する ISO 8601 規格のプロファイルである。
目次
1. はじめに ............................................ 2
2. 定義 ................................................ 3
3. 2 桁年 .............................................. 4
4. ローカル時刻 ........................................ 4
4.1. 協定世界時 (UTC) ................................. 4
4.2. ローカルオフセット ............................... 5
4.3. 不明なローカルオフセットの慣例 ................... 5
4.4. 修飾なしローカル時刻 ............................. 5
5. 日付および時刻形式 ................................. 6
5.1. 順序付け ......................................... 6
5.2. 人間にとっての可読性 ............................. 6
5.3. まれに使用されるオプション ....................... 7
5.4. 冗長な情報 ....................................... 7
5.5. 単純性 ........................................... 7
5.6. インターネット日付/時刻形式 ...................... 8
5.7. 制限 ............................................. 9
5.8. 例 ............................................... 10
6. 参考文献 ............................................ 10
7. セキュリティに関する考慮事項 ....................... 11
Klyne, et. al. Standards Track [Page 1]
RFC 3339 Date and Time on the Internet: Timestamps July 2002
Appendix A. ISO 8601 収集 ABNF ........................ 12
Appendix B. 曜日 ....................................... 14
Appendix C. うるう年 ................................... 14
Appendix D. うるう秒 ...............................,... 15
謝辞 ................................................... 17
著者の連絡先 ........................................... 17
完全な著作権表示 ....................................... 18
1. はじめに
日付および時刻形式は、インターネット上で多くの混乱と相互運用性の
問題を引き起こす。本文書は、発生する多くの問題に対処し、
インターネットプロトコルにおいて日付および時刻を表現し使用する際の
一貫性と相互運用性を向上させるための推奨事項を示す。
本文書は、グレゴリオ暦を用いた日付および時刻の表現に関する
ISO 8601 [ISO8601]
規格のインターネットプロファイルを含む。
インターネットプロトコルに日付および時刻値が現れる方法は数多く
あり得るが、本文書では 1 つの一般的な用法、すなわちインターネット
プロトコルイベントのタイムスタンプだけに焦点を当てる。この限定的な
考察には、次のような帰結がある。
o すべての日付および時刻は「現在の時代」、すなわち 0000AD から
9999AD の間のどこかにあるものと仮定する。
o 表現されるすべての時刻は、協定世界時 (UTC) との明示された関係
（オフセット）を持つ。（これは、ローカル時刻と場所は既知であって
も、UTC との実際の関係が政治家または管理者の未知または知り得ない
行動に依存し得る、スケジューリングアプリケーションにおける一部の
用法とは異なる。ニューヨークにおける 2005 年 3 月 23 日 17:00 に
対応する UTC 時刻は、夏時間に関する管理上の決定に依存する可能性が
ある。本仕様は、そのような考慮事項を明確に避ける。）
o タイムスタンプは、UTC の導入前に発生した時刻を表現できる。その
ようなタイムスタンプは、その時点で利用可能な最善の実務を用いて、
世界時に相対的に表現される。
o 日付および時刻表現は、時間上の一点を示す。期間または間隔の記述は、
ここでは扱わない。
Klyne, et. al. Standards Track [Page 2]
RFC 3339 Date and Time on the Internet: Timestamps July 2002
2. 定義
本文書におけるキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL",
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
および "OPTIONAL" は、RFC 2119 [RFC2119] で説明されている
とおりに解釈される。
UTC Bureau International des Poids et Mesures (BIPM) に
よって維持される協定世界時。
second 国際単位系における時刻測定の基本単位。これは、外部
磁場によって乱されていない基底状態のセシウム 133 原子
の超微細遷移によって吸収または放出されるマイクロ波光の
9,192,631,770 周期の継続時間として定義される。
minute 60 秒からなる時間の期間。ただし、分の中でうるう秒を
どのように表記するかについては、section 5.7 および
Appendix D の制限も参照のこと。
hour 60 分からなる時間の期間。
day 24 時間からなる時間の期間。
leap year グレゴリオ暦において 366 日を持つ年。うるう年とは、
その年数が 4 で割り切れる年である。ただし、それが世紀年
（すなわち 100 で割り切れる年）である場合は、さらに
400 でも割り切れなければならない。
ABNF Augmented Backus-Naur Form。プロトコルまたは言語で
許容される文字列を表現するために用いられる形式であり、
[ABNF] で定義される。
Email Date/Time Format
RFC 2822 [IMAIL-UPDATE] で定義される Internet Mail で
使用される日付/時刻形式。
Internet Date/Time Format
本文書の section 5 で定義される日付形式。
Timestamp この用語は本文書において、ある時間上の一点の曖昧でない
表現を指すために用いられる。
Z 時刻に付加された場合に UTC オフセット 00:00 を示す接尾辞。
ICAO 音声アルファベットにおける文字 "Z" の表現から、
しばしば "Zulu" と発音される。
Klyne, et. al. Standards Track [Page 3]
RFC 3339 Date and Time on the Internet: Timestamps July 2002
時間尺度に関する詳細については、[NTP] の Appendix E、
[ISO8601] の Section 3、および適切な ITU 文書 [ITU-R-
TF] を参照のこと。
3. 2 桁年
次の要件は、2 桁年の曖昧さの問題に対処するためのものである。
o インターネットプロトコルは、日付に 4 桁年を生成しなければ
ならない（MUST）。
o 2 桁年の使用は非推奨である。2 桁年を受信した場合、不正確な
解釈がプロトコルまたは処理の失敗を引き起こさない場合にのみ
受け入れるべきである（例えば、ログまたはトレース目的にのみ
使用される場合）。
o 2 桁年を使用するプログラムが、1999 年以降の年を 3 桁として
表現する可能性がある。これは、プログラムが単に年から 1900 を
差し引き、桁数を確認しない場合に発生する。そのような壊れた
ソフトウェアが生成した日付を堅牢に扱いたいプログラムは、
3 桁年に 1900 を加えてもよい。
o 2 桁年を使用するプログラムが、1999 年以降の年を ":0", ":1",
... ":9", ";0", ... として表現する可能性がある。これは、
プログラムが単に年から 1900 を差し引き、その 10 年単位の値を
US-ASCII 文字のゼロに加える場合に発生する。そのような壊れた
ソフトウェアが生成した日付を堅牢に扱いたいプログラムは、
数字でない 10 年単位を検出し、適切に解釈すべきである。
2 桁年の問題は、インターネットプロトコルで使用されるすべての日付
および時刻が完全に修飾されなければならない理由を十分に示している。
4. ローカル時刻
4.1. 協定世界時 (UTC)
ローカルタイムゾーンに関する夏時間規則は非常に複雑であり、予測不能な
時点で現地法に基づいて変更され得るため、真の相互運用性は協定世界時
(UTC) を使用することで最もよく達成される。本仕様は、ローカル
タイムゾーン規則には対応しない。
Klyne, et. al. Standards Track [Page 4]
RFC 3339 Date and Time on the Internet: Timestamps July 2002
4.2. ローカルオフセット
ローカル時刻と UTC の間のオフセットは、しばしば有用な情報である。
例えば、電子メール（RFC2822, [IMAIL-UPDATE]）では、ローカル
オフセットは迅速な応答の可能性を判断するための有用なヒューリスティック
を提供する。ローカルオフセットにアルファベット文字列でラベルを付ける
試みは、過去に不十分な相互運用性をもたらした [IMAIL],
[HOST-REQ]。その結果、RFC2822 [IMAIL-UPDATE] は数値
オフセットを必須とした。
数値オフセットは「ローカル時刻から UTC を引いたもの」として計算される。
したがって、UTC における等価な時刻は、ローカル時刻からオフセットを
差し引くことで決定できる。例えば、18:50:00-04:00 は 22:50:00Z と
同じ時刻である。（この例は、負のオフセットがオフセットの絶対値を
加えることによって扱われることを示している。）
NOTE: ISO 8601 に従い、数値オフセットは UTC と整数分だけ異なる
タイムゾーンのみを表す。しかし、多くの歴史的なタイムゾーンは、
UTC と非整数分だけ異なる。そのような歴史的なタイムスタンプを正確に
表現するには、アプリケーションはそれらを表現可能なタイムゾーンに
変換しなければならない。
4.3. 不明なローカルオフセットの慣例
UTC における時刻は既知であるが、ローカル時刻へのオフセットが不明な
場合、これは "-00:00" のオフセットで表現できる。これは、指定された
時刻について UTC が好ましい基準点であることを含意する "Z" または
"+00:00" のオフセットとは意味的に異なる。RFC2822
[IMAIL-UPDATE] は、電子メールについて同様の慣例を説明している。
4.4. 修飾なしローカル時刻
現在インターネットに接続されている多数の機器は、内部時計をローカル
時刻で動作させており、UTC を認識していない。インターネットには仕様を
作成する際に現実を受け入れる伝統があるが、これは相互運用性を犠牲に
して行うべきではない。修飾なしローカルタイムゾーンの解釈は、地球上の
およそ 23/24 で失敗するため、修飾なしローカル時刻の相互運用性の問題は
インターネットにとって許容できないと見なされる。ローカル時刻で構成
され、対応する UTC オフセットを認識せず、他のインターネットシステム
との時刻同期に依存するシステムは、UTC との正しい同期を保証する機構を
使用しなければならない（MUST）。適切な機構の例は次のとおりである。
o Network Time Protocol [NTP] を使用して UTC の時刻を取得する。
Klyne, et. al. Standards Track [Page 5]
RFC 3339 Date and Time on the Internet: Timestamps July 2002
o 同じローカルタイムゾーン内の別のホストを、インターネットへの
ゲートウェイとして使用する。このホストは、他のホストに送信される
修飾なしローカル時刻を訂正しなければならない（MUST）。
o ローカルタイムゾーンおよび夏時間規則の設定について、ユーザーに
入力を求める。
5. 日付および時刻形式
この節では、日付および時刻形式に望ましい性質について論じ、
インターネットプロトコルで使用するための ISO 8601 のプロファイルを
定義する。
5.1. 順序付け
日付および時刻の構成要素が、精度の低いものから高いものへ順に並べられる
場合、有用な性質が得られる。日付および時刻のタイムゾーンが同じ
（例えば、すべて UTC）であり、同じ文字列を用いて表現され（例えば、
すべて "Z" またはすべて "+00:00"）、かつすべての時刻が同じ桁数の
小数秒を持つと仮定すると、日付および時刻文字列は文字列として
（例えば C の strcmp() 関数を用いて）ソートでき、その結果、
時刻順の列が得られる。任意の句読点が存在すると、この特性は損なわれる。
5.2. 人間にとっての可読性
人間にとっての可読性は、インターネットプロトコルの価値ある特徴である
ことが示されてきた。人間が読めるプロトコルは、telnet がテスト
クライアントとして十分であることが多く、ネットワーク解析器を
プロトコルの知識で修正する必要がないため、デバッグのコストを大幅に
低減する。一方で、人間にとっての可読性は、時として相互運用性の問題を
引き起こす。例えば、日付形式 "10/11/1996" は国ごとに異なる解釈を
されるため、グローバルな交換にはまったく適していない。さらに、
[IMAIL] の日付形式は、任意のテキスト文字列が許可されると人々が
思い込み、3 文字の略称を他の言語に翻訳したり、生成しやすい日付形式
（例えば C 関数 ctime が用いる形式）に置き換えたりしたときに、
相互運用性の問題をもたらした。このため、人間にとっての可読性と
相互運用性の間でバランスを取らなければならない。
すべての国の慣習に照らして可読な日付および時刻形式は存在しないため、
インターネットクライアントは、日付を地域に適した表示形式へ変換する
用意をしておくべきである（SHOULD）。これには UTC をローカル時刻に
変換することが含まれ得る。
Klyne, et. al. Standards Track [Page 6]
RFC 3339 Date and Time on the Internet: Timestamps July 2002
5.3. まれに使用されるオプション
まれに使用されるオプションを含む形式は、相互運用性の問題を引き起こす
可能性が高い。これは、まれに使用されるオプションがアルファテストや
ベータテストで使用される可能性が低く、そのため解析におけるバグが
発見されにくいからである。まれに使用されるオプションは、相互運用性の
ため、可能な限り必須にするか省略するべきである。
以下で定義する形式には、まれに使用されるオプションは 1 つだけ含まれる:
秒の小数部である。これは、日付/時刻スタンプの厳密な順序付けを必要とする
アプリケーション、または通常と異なる精度要件を持つアプリケーションで
のみ使用されることが期待される。
5.4. 冗長な情報
日付/時刻形式が冗長な情報を含む場合、その冗長な情報が対応しなくなる
可能性が生じる。例えば、日付/時刻形式に曜日を含めると、曜日が誤って
いるが日付は正しい、またはその逆である可能性が生じる。日付から曜日を
計算することは難しくないため（Appendix B を参照）、曜日は
日付/時刻形式に含めるべきではない。
5.5. 単純性
ISO 8601 [ISO8601] で規定される日付および時刻形式の完全な集合は、
複数の表現および部分表現を提供しようとするため、かなり複雑である。
Appendix A には、ISO 8601 の完全な構文を ABNF に変換しようとする
試みが含まれる。インターネットプロトコルにはやや異なる要件があり、
単純性は重要な特性であることが示されてきた。さらに、インターネット
プロトコルでは、真の相互運用性を達成するため、通常データの完全な
指定が必要である。したがって、ISO 8601 の完全な文法は、ほとんどの
インターネットプロトコルにとって複雑すぎると見なされる。
次の節では、インターネット上で使用するための ISO 8601 のプロファイルを
定義する。これは、ISO 8601 拡張形式の適合する部分集合である。ほとんどの
フィールドおよび句読点を必須にすることで、単純性が達成される。
Klyne, et. al. Standards Track [Page 7]
RFC 3339 Date and Time on the Internet: Timestamps July 2002
5.6. インターネット日付/時刻形式
ISO 8601 [ISO8601] 日付の次のプロファイルは、インターネット上の
新しいプロトコルで使用されるべきである（SHOULD）。これは [ABNF] で
定義される構文記述記法を用いて規定される。
date-fullyear = 4DIGIT
date-month = 2DIGIT ; 01-12
date-mday = 2DIGIT ; 月/年に基づく 01-28, 01-29, 01-30, 01-31
time-hour = 2DIGIT ; 00-23
time-minute = 2DIGIT ; 00-59
time-second = 2DIGIT ; うるう秒規則に基づく 00-58, 00-59, 00-60
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
date-time = full-date "T" full-time
NOTE: [ABNF] および ISO8601 に従い、この構文における "T" および
"Z" 文字は、それぞれ小文字の "t" または "z" であってもよい。
この日付/時刻形式は、大文字 'A'-'Z' と小文字 'a'-'z' を区別する
一部の環境またはコンテキスト（例えば XML）で使用される場合がある。
そのような環境でこの形式を使用する仕様は、日付/時刻構文で使用される
文字 'T' および 'Z' が常に大文字でなければならないように、日付/時刻
構文をさらに制限してもよい（MAY）。この形式を生成するアプリケーション
は、大文字を使用すべきである（SHOULD）。
NOTE: ISO 8601 は、日付と時刻を "T" で区切ることを定義している。
この構文を使用するアプリケーションは、可読性のため、full-date と
full-time を（例えば）空白文字で区切って指定することを選択してもよい。
Klyne, et. al. Standards Track [Page 8]
RFC 3339 Date and Time on the Internet: Timestamps July 2002
5.7. 制限
文法要素 date-mday は、現在の月における日番号を表す。最大値は月および
年に基づいて次のように変化する。
月番号 月/年 date-mday の最大値
------------ ---------- --------------------------
01 1月 31
02 2月、平年 28
02 2月、うるう年 29
03 3月 31
04 4月 30
05 5月 31
06 6月 30
07 7月 31
08 8月 31
09 9月 30
10 10月 31
11 11月 30
12 12月 31
Appendix C には、ある年がうるう年であるかを判定するための C コードの
例が含まれる。
文法要素 time-second は、うるう秒が発生する月の終わりに値 "60" を
持ってもよい -- これまでのところ、6 月（XXXX-06-30T23:59:60Z）または
12 月（XXXX-12-31T23:59:60Z）である。うるう秒の表については
Appendix D を参照のこと。うるう秒が差し引かれる可能性もあり、その場合
time-second の最大値は "58" である。それ以外のすべての時点では、
time-second の最大値は "59" である。さらに、"Z" 以外のタイムゾーンでは、
うるう秒の時点はゾーンオフセットによって移動する（したがって、世界中で
同じ瞬間に発生する）。
うるう秒は、遠い将来について予測することはできない。International Earth
Rotation Service は、数週間前にうるう秒を告知する告示 [IERS] を
公表する。アプリケーションは、うるう秒が告知されるまでは、挿入される
うるう秒を含むタイムスタンプを生成すべきではない。
ISO 8601 は時を "24" とすることを許可しているが、本 ISO 8601 プロファイル
は混乱を減らすため、時について "00" から "23" までの値のみを許可する。
Klyne, et. al. Standards Track [Page 9]
RFC 3339 Date and Time on the Internet: Timestamps July 2002
5.8. 例
以下は、インターネット日付/時刻形式の例である。
1985-04-12T23:20:50.52Z
これは、UTC における 1985 年 4 月 12 日の 23 時から 20 分 50.52 秒後を
表す。
1996-12-19T16:39:57-08:00
これは、UTC から -08:00 のオフセット（Pacific Standard Time）を持つ
1996 年 12 月 19 日の 16 時から 39 分 57 秒後を表す。これは UTC では
1996-12-20T00:39:57Z と等価であることに注意。
1990-12-31T23:59:60Z
これは、1990 年末に挿入されたうるう秒を表す。
1990-12-31T15:59:60-08:00
これは、UTC より 8 時間遅れの Pacific Standard Time における同じ
うるう秒を表す。
1937-01-01T12:00:27.87+00:20
これは、オランダ時刻の 1937 年 1 月 1 日正午と同じ瞬間を表す。
オランダの標準時は、1909-05-01 から 1937-06-30 まで、法律により UTC より
正確に 19 分 32.13 秒進んでいた。このタイムゾーンは HH:MM 形式を用いて
正確に表現できないため、このタイムスタンプは最も近い表現可能な UTC
オフセットを使用している。
6. 参考文献
[ZELLER] Zeller, C., "Kalender-Formeln", Acta Mathematica, Vol.
9, Nov 1886.
[IMAIL] Crocker, D., "Standard for the Format of Arpa Internet
Text Messages", STD 11, RFC 822, August 1982.
[IMAIL-UPDATE] Resnick, P., "Internet Message Format", RFC 2822,
April 2001.
[ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
Klyne, et. al. Standards Track [Page 10]
RFC 3339 Date and Time on the Internet: Timestamps July 2002
[ISO8601] "Data elements and interchange formats -- Information
interchange -- Representation of dates and times", ISO
8601:1988(E), International Organization for
Standardization, June, 1988.
[ISO8601:2000] "Data elements and interchange formats -- Information
interchange -- Representation of dates and times", ISO
8601:2000, International Organization for
Standardization, December, 2000.
[HOST-REQ] Braden, R., "Requirements for Internet Hosts --
Application and Support", STD 3, RFC 1123, October
1989.
[IERS] International Earth Rotation Service Bulletins,
<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.
[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.
7. セキュリティに関する考慮事項
サイトのローカルタイムゾーンは、システムが監視されている可能性が
低く、セキュリティプローブの影響を受けやすい時刻を判断するために
有用である可能性があるため、一部のサイトは時刻を UTC のみで出力する
ことを望むかもしれない。他のサイトは、これを偏執によって有用な機能が
失われるものと考えるかもしれない。
Klyne, et. al. Standards Track [Page 11]
RFC 3339 Date and Time on the Internet: Timestamps July 2002
Appendix A. ISO 8601 収集 ABNF
この情報は、ISO 8601 の 1988 年版に基づいている。2000 年改訂版では、
いくつかの変更がある可能性がある。
ISO 8601 は、それが定義する日付および時刻形式について正式な文法を
規定していない。以下は、ISO 8601 から正式な文法を作成しようとする
試みである。これは参考情報のみであり、誤りを含む可能性がある。
ISO 8601 が権威ある参照であり続ける。
ISO 8601 の曖昧さのため、いくつかの解釈を行う必要があったことに
注意。第一に、ISO 8601 は基本形式と拡張形式の混合が許容されるかどうか
について明確ではない。この文法は混合を許容する。ISO 8601 は、24 時が
許容されるのは分と秒が 0 の場合だけかどうかについて明確ではない。
これは、24 時が任意のコンテキストで許容されるものと仮定する。
section 5.7 の date-mday に関する制限が適用される。ISO 8601 は、
"T" が一部の状況で省略されてもよいと述べている。この文法は曖昧さを
避けるため "T" を要求する。ISO 8601 はまた（section 5.3.1.3 で）、
1 未満の小数には "0" を前置しなければならないと要求している。
ISO 8601 の Annex B.2 は、小数に "0" が前置されていない例を示している。
この文法は section 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 は月曜日、7 は日曜日
date-mday = 2DIGIT ; 月/年に基づく 01-28, 01-29, 01-30, 01-31
date-yday = 3DIGIT ; 年に基づく 001-365, 001-366
date-week = 2DIGIT ; 年に基づく 01-52, 01-53
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 ["-"])
Klyne, et. al. Standards Track [Page 12]
RFC 3339 Date and Time on the Internet: Timestamps July 2002
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-hour = 2DIGIT ; 00-24
time-minute = 2DIGIT ; 00-59
time-second = 2DIGIT ; うるう秒規則に基づく 00-58, 00-59, 00-60
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]
iso-date-time = date "T" time
継続時間:
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)
Klyne, et. al. Standards Track [Page 13]
RFC 3339 Date and Time on the Internet: Timestamps July 2002
期間:
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
Appendix B. 曜日
以下は、Zeller の合同式 [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]);
}
Appendix C. うるう年
以下は、ある年がうるう年であるかを計算する 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));
}
Klyne, et. al. Standards Track [Page 14]
RFC 3339 Date and Time on the Internet: Timestamps July 2002
Appendix D. うるう秒
うるう秒に関する情報は、以下で確認できる。
<http://tycho.usno.navy.mil/leapsec.html>。特に、そこでは
次のように記されている。
UTC にうるう秒を導入する決定は、International Earth Rotation Service
(IERS) の責任である。CCIR 勧告によれば、第 1 の優先機会は 12 月末
および 6 月末であり、第 2 の優先機会は 3 月末および 9 月末である。
必要な場合、うるう秒の挿入は UTC における 1 日の終わりに追加の 1 秒
として発生し、YYYY-MM-DDT23:59:60Z という形式のタイムスタンプで表現
される。うるう秒はすべてのタイムゾーンで同時に発生するため、
タイムゾーンの関係は影響を受けない。うるう秒時刻の例については
section 5.8 を参照のこと。
次の表は、United States Naval Observatory が維持する表からの抜粋である。
元データは次の場所にある。
<ftp://maia.usno.navy.mil/ser7/tai-utc.dat>
Klyne, et. al. Standards Track [Page 15]
RFC 3339 Date and Time on the Internet: Timestamps July 2002
この表は、うるう秒の日付、およびそのうるう秒の後における時刻標準
TAI（うるう秒によって調整されない）と UTC の差を示す。
UTC 日付 うるう秒後の TAI - UTC
-------- ---------------------------
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
Klyne, et. al. Standards Track [Page 16]
RFC 3339 Date and Time on the Internet: Timestamps July 2002
謝辞
次の人々は、本書の以前の形に対して有用な助言を提供した: Ned Freed,
Neal McBurnett, David Keegel, Markus Kuhn, Paul Eggert and Robert Elz.
IETF Calendaring/Scheduling ワーキンググループのメーリングリストの参加者、
および time zone メーリングリストの参加者にも感謝する。
次の査読者は、現在の改訂に対して有用な提案を寄せた: Tom Harsch,
Markus Kuhn, Pete Resnick, Dan Kohn。Paul Eggert は、うるう秒および
タイムゾーンオフセットの微妙な点に関して、多くの慎重な観察を提供した。
次の人々は、以前のドラフトに対する訂正および改善を指摘した:
Dr John Stockton, Jutta Degener, Joe Abley, and Dan Wing。
著者の連絡先
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
Phone: +44 11 8903 8903
Fax: +44 11 8903 9000
EMail: GK@ACM.ORG
Klyne, et. al. Standards Track [Page 17]
RFC 3339 Date and Time on the Internet: Timestamps July 2002
Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved.
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.
謝辞
RFC Editor 機能への資金提供は、現在 Internet Society によって
行われている。
Klyne, et. al. Standards Track [Page 18]