ISO 8601(RFC 3339)形式

Edit New

RFC 3339 の日時形式

[14] RFC 3339の日時形式は、 IETF が RFC 3339 Date and Time on the Internet: Timestamps で規定した日時形式です。

[192] RFC 3339の日時形式は ISO 8601の日時形式のプロファイルであり、 21世紀に入ってから作られた色々な IETF のプロトコルで採用されています。

[101] 2006-04-13T14:12:53.4242+05:30 は、 UTC から地方時における、 を表しています。

代替

[31] RFC 3339の日時形式は近年の IETF の仕様ではよく使われていますが、 それ以外ではあまり使われていません。 IETF 内でも細かなバリエーションがあって統一しきれていません。 IETF が規定する仕様を利用する場合を除き、本日時形式は使うべきではなさそうです。

[184] 類似した日時形式の中では HTMLの日時形式がより厳密に規定されており、 利用しやすくなっています。

仕様書

[196] RFC 3339 は IETF 標準化過程RFC です。 状態は提案標準です (インターネット標準ではありません)。

[197] なお、 RFC は、提案標準かインターネット標準かいずれかに関わらず、 採用すると定められた場面以外での強制力はありません。

[198] Atom 1.0 は RFC 3339 を使うと定めているので、 RFC 3339の日時形式を使わなければなりません。

[199] 新しい Web API で使う JSON データ形式を設計するとき、 日時の表現に RFC 3339の日時形式を使う義務はありません。

[240] インターネットメールの Date: ヘッダーでは RFC 5322の日時形式を使うと定められていて、 RFC 3339の日時形式は使えません。

暦法

[186] RFC 3339 内には ISO 8601 のグレゴリオ暦記述法を使う、 というような簡単な言及のみしかありません。 不親切ですね (ISO 8601 は有料です)。

[241] RFC 3339の日時形式は ISO 8601のプロファイルですので、 ISO 8601 の規定が適用されます。 ISO 8601暦

[242] つまり RFC 3339 の暦法も先発グレゴリオ暦です。

[243] 明治改暦やグレゴリオ改暦より前の日時も記述できますが、 先発グレゴリオ暦で記述しなければなりません。

[245] 旧暦、イスラム暦、ユリウス暦、 その他の暦法には対応していません。 グレゴリオ暦に変換して記述しなければなりません。

[246] RFC 3339の日時形式はあくまで機械可読な情報交換用の構文に過ぎません。 人間用に表示するときは、 利用者に応じて適切に変換することが期待されます (>>83)。

構文

[85] 構文は RFC 3339 で ABNF により規定されています >>82。

[86] ISO 8601 のプロファイルである >>82 とされており、 ISO 8601 と見比べれば自明ということなのか、規定された構文の意味はほとんど説明がありません。 不親切ですね (ISO 8601 は有料です)。

[87] また、一般に RFC 3339の日時形式とされるものは生成規則 date-time が受理する言語と解されていますが、 RFC 3339 自身にはどの生成規則がプロトコル等に埋め込まれて使われるべきものかが明記されていません。 よって、RFC 3339 は日時形式を1つ規定しているという解釈もあれば、 日時、日付、時刻など複数の形式を規定しているという解釈もあります (変種の項も参照)。 ただ、 RFC 3339 に例示があるのはすべて date-time です。

[247] 「RFC 3339 の定める日時の形式」 と 「RFC 3339 の生成規則 date-time」 が同じなのかどうかも、仕様書の厳密な解釈の問題としては存在します。 (>>104 も参照。)

[200] 近代的な標準技術仕様書として見れば低品質と評さざるを得ませんが、 この時代の RFC ではまともな方でした。
[248] こういう曖昧さを内包し、しかもそのことを見えにくくしてしまうのが、 ABNF のような形式言語による標準仕様の記述が好ましくないと Web標準の世界で考えられるようになった一因ですね。

[89] date-time は、 full-date、T、full-time を連ねたものです。 >>82 一般には1つの日時を表すと解されています。

  1. full-date
  2. |
    1. T
  3. full-time

[201] ここで区切りに使う T は、 ISO 8601 で定められたものです。 語源は time と思われますが、 深い意味はなく、単なる区切りの記号と理解するべきものです。

[244] この T があるために、 RFC 3339の日時形式は世界のどこの地域のどこの言語の日時表示としても不自然で、 専ら機械処理用の日時形式としてしか利用できなくなっています。

なお、 >>17 も参照。

[90] full-date は、 年月日を - で連結したものです >>82。 一般には1つの日付を表すと解されています。

  1. 年
  2. -
  3. 月
  4. -
  5. 日

[91] full-time は、時刻と時差を連ねたものです >>82。

  1. 時刻
  2. 時差

[95] 時刻は、時、分、秒と秒の小数部を : で連結したものです。 >>82

  1. 時
  2. :
  3. 分
  4. :
  5. 秒と秒の小数部

[93] 月は、 01 - 12 の2桁のASCII数字です >>82。

[94] 日は、 01 - (28, 29, 30, 31 のいずれか) の2桁のASCII数字で、最大値は年と月による日の数です。 >>82

[96] 時は、 00 - 23 の2桁のASCII数字です >>82。

[106] ISO 8601 では認められている 24 は、認められません >>82。

[98] 分は、 00 - 59 の2桁のASCII数字です >>82。

[187] 月、日、時、分はいずれも2桁のASCII数字ですから、 1桁の場合先導0が必須となります。

[188] 2019-3-5T4:3:3 は不正です。 2019-03-05T04:03:03 としなければなりません。

年

[92] 年は、4桁のASCII数字です >>82。

値域制限はありません。
  1. ASCII数字
  2. ASCII数字
  3. ASCII数字
  4. ASCII数字

[19] ISO 8601 (の RFC 3339 制定当時の版) に従い、 年号は4桁でなければなりません。 1万年以降や0年よりも前は記述できません。

[1] 2000年問題には対応していますが, 10000年問題には対応出来ません。 ISO 8601の日時形式
[216] 将来的に5桁以上も認める形に拡張できるかもしれませんが、 固定長であるという特徴が失われるので注意する必要があります。 また、拡張したものは RFC 3339の日時形式ではなくなります。

[2] 西暦1年〜西暦999年を表すには先導0 を補わなければならないことに注意が必要です。

[259] 0123 は、です。

[202] 暦 (>>242) の違いにも注意が必要です。 ISO 8601の年

[211] ISO 8601 の年は西暦年です。

[212] 元号年、民国紀元、ヒジュラ紀元など各国の紀年法には対応していません。 西暦年に変換して記述しなければなりません。

[215] RFC 3339の日時形式はあくまで機械可読な情報交換用の構文に過ぎません。 人間用に表示するときは、 利用者に応じて適切に変換することが期待されます (>>83)。

秒と秒の小数部

[97] 秒は、 00 - (58, 59, 60 のいずれか) の2桁のASCII数字で、最大値は閏秒規則によります >>82。

[99] 秒の小数部は、 . の後に1桁以上の ASCII数字を連ねたものです >>82。

  1. ASCII数字
  2. ASCII数字
  3. ?
    1. .
    2. +
      1. ASCII数字

[144] 秒の小数部は、構文上、任意の桁数が認められています。 しかし、その精度をどう解釈するべきなのか (例えば末尾に 0 があるのとないのとでは意味が違うのかどうか、実装の都合で丸めて解釈していいのかどうか、など) や、 プロトコル依存で桁数の上限を定めていいのかどうかなど、 詳細は仕様書に何も書かれていません。

閏秒

[18] RFC 3339 は閏秒に対応しています。 正閏秒として60秒を使うことができ、 負閏秒では59秒を使いません >>82。

[105] 応用は、 正閏秒が広告されるまで、 これを含むタイムスタンプを生成するべきではありません。 >>82

[32] 実装がこれを正しく扱えるのかどうかは定かではありません。 多くのシステムは閏秒のないUTCを採用しているので、 閏秒のタイムスタンプを生成することはありませんし、 閏秒のタイムスタンプを与えられたとき、 前後の秒と認識してしまうか、 不正なタイムスタンプとみなされてしまう危険性があります。 あるいは閏秒かどうかの判断を回避するため、すべての分で60秒を認めてしまう実装もあるかもしれません。

[260] 不正な閏秒が記述されていたとき、これを解釈する実装がどう処理するべきなのかは、 仕様書には書かれていません。不正な入力として拒絶される可能性もあれば、 次の秒と解釈される可能性も、前の秒と解釈される可能性もあります。 まったく違う値と誤解する実装もあるかもしれません。

[261] このような動作の違いは、ときにセキュリティー問題を引き起こす危険性があります。

[262] RFC 3339 に限った問題ではありませんが、 閏秒の実施の有無が決定するまで、 ある文字列が正当な値かどうかが定まらない (実施の有無が決定する前と後とで、その入力に対する処理結果が変化する可能性がある) のは、 実装上よくよく注意が必要です。

時間帯

[4] UTC との時差を記述することができます。

[80] これは fingerprinting vector です。 日時のプライバシー

[100] 時差は、 Z または数値時差です。 数値時差は、符号、時、:、分を連ねたものです。 符号は、 + または - です。 >>82

  1. |
    1. Z
    2. =
      1. |
        1. +
        2. -
      2. ASCII数字
      3. ASCII数字
      4. :
      5. ASCII数字
      6. ASCII数字

[220] 日本時間 (中央標準時) は +09:00 となります。

[78] 時差は分単位です。秒単位の時差は記述できず、 適当な分単位の時差になおして記述するしかありません >>79。

[263] 現代の各国政府の定める標準時・夏時刻はこれでカバーできていますが、 過去の日時は記述できないことがあります。 また、現代でも、船内時など私的な日時の記述はできない可能性があります。

[185] RFC 822の日時形式とは違って、時と分の間に : が必須となっていることに注意。 これが欠けている誤った形式が使われることもあります。

[221] +09:00 が正しく、 +0900 は誤りです。

[81] UTC での時刻はわかるものの地方時が不明なことを示す特別な時差表記 -00:00 があります。

[39] これは RFC 822の日時形式由来の慣習で、 ISO 8601の日時形式にはない独自の解釈です。 他の ISO 8601のプロファイルや HTMLの日時形式はこの解釈を採用していません。 (この慣習は、 ISO 8601 に適合しない疑いがあります。) -00:00

[252] なお、紛らわしいですが、 時差の不明な floating time とは異なるので注意。

[264] 標準時や夏時刻は、政府の決定で変更されることが (かなりの頻度で) あります。 将来の日時を記述したいなら、 現在の制度が変更されない期待のもとで時差を記述するほかありません。

[265] 「来年の3月10日の9時12分」を記述したいとき、 「来年の3月10日」時点の標準時での「9時12分」を意味していることが多そうですが、 RFC 3339の日時形式だけでは (厳密には) 記述できません。

指示子

[17] T と Z は、大文字でも小文字でも構いませんが、 大文字を使うべきです >>82。

[102] XML など大文字と小文字を区別する状況で使うプロトコルは、 大文字でなければならないと制約しても構いません。 >>82

[103] インターネットのプロトコルでも、値の大文字と小文字を区別できない状況は稀です。 そもそも ISO 8601 は大文字を使えない状況で小文字で代用しても良いとしているだけなので、 そのような状況がほとんど考えられないインターネットの新しいプロトコル向けの RFC 3339 がなぜわざわざ小文字も認めることにしたのかは、謎です。 (確かに IETF では大文字と小文字を区別しないプロトコルが伝統的ではあったのですが...)

[26] 日時の境界は、 ABNF 構文では T (大文字または小文字) とされています。しかし NOTE で、 応用は可読性のため間隔その他の他の区切りを選んでも構わない >>82 とされています。 選択次第で ISO 8601のプロファイルの範囲を逸脱してしまいます。

[104] ABNF では T に限定されているということは、 「RFC 3339 の date-time」と明示的に参照しているプロトコルにおいては、 T を使うことが要求されていると解釈するべきでしょうか。 「RFC 3339 の日時」のような曖昧な参照方法のプロトコルは、 他の区切り文字が認められている可能性があります。

処理

[145] 構文的に不正な値や値域を外れた値をどう解釈するべきかにはまったく言及されていません。

[249] 構文的に適正でも受信した装置が処理できない値 (過去すぎる、 未来すぎるなど) をどう処置するべきかにもまったく言及がありません。

[250] 適切かどうか判断し難い値や適切かどうかが変化した値 (具体的には閏秒) を受信した時どう処理するべきかは不明です (>>260)。

[251] 60秒と書かれた値は閏秒の実施不実施が決定されるまで適切な値かどうか不定ですし、 不実施が決定されてからは不適切な値になります。

レンダリング

[83] クライアントは、言語や時差に応じて適切に表示できるようにするべきです >>82。 日時表示

[181] つまり本日時形式はあくまでプロトコルの情報交換に用いられる構文を定めるものに過ぎず、 それを利用者エージェントがどのように利用者に提示するかは、 利用者エージェントの裁量の範囲内 (実装の品質の問題) ということになります。

[182] 例えば英語圏では月名を数字ではなく英語の名前で表示するのが適切かもしれません。

[253] 例えば日本では年を元号年と西暦年の併記で表示するべきかもしれません。

[183] 「○分前」のような ambtime 形式で表示するのが便利な場面もあるかもしれません。

文脈

[84] 新しいインターネットのプロトコルでは、 本形式を使うべきです >>82。

[110] RFC 3339 date-time の採用例
[116] RFC 3339 Section 5.6 Internet Date/Time Format 形式の採用例
[124] RFC 3339 の日時形式の採用例

[266] 実はオリジナルの RFC 3339 を参照している規格はそれほど多くはありません。 ほとんどは変種を使っています。変種の項を参照。

[34] ScalaでRSSフィードの処理を書いてみたら思ったより大変でした - argius note ( 版) http://argius.hatenablog.jp/entry/20130830/1377867921

RSS2.0の日付もRFC 3339になっているケースが割とありました。

[11] 本来は RFC 822の日時形式

変種

[204] RFC 3339の日時形式には変種が無数にあります。 それらが「RFC 3339の日時形式」と (不正確に) いわれることがあり、 円滑な情報交換の障害となっています。

[205] これだけバリエーションが多いというのは、 RFC 3339 が要求に十分に応えられていない (が要求に近いものではある) ことを表し、 標準化戦略が不完全だったことを意味しています。 ふつうなら標準仕様を改訂すれば済むことですが、 RFC の改訂コストが極めて高い IETF の標準化手続きのためか、 長らく放置されています。
[254] >>147 のように追加の制約が意味不明だったりすると、 何のために標準規格があって何のためにそれを採用したのか、 わからなくなってしまいますね。
[146] フォトコレクション | docomo Developer support | NTTドコモ () https://dev.smt.docomo.ne.jp/?p=docs.api.page&api_name=photo_collection&p_name=api_1

タイムゾーンは任意に設定してよい。

RFC 3339 の date-time フォーマットで 秒の1の位まで指定する。

サンプル値) yyyy-mm-ddThh:mi:ss+09:00 (JSTの例)

yyyy-mm-ddThh:mi:ssZ (UTCの例)

[147] 「秒の1の位まで指定する」の意図が不明。秒の小数部は使えないのだろうか。

RFC 2518

[8] RFC 2518 には、 RFC 3339 になるの前の I-D の規定の一部がコピペされています。 ISO 8601 形式であること、 ABNF 構文、特別な時間帯である -00:00 が含まれていますが、それ以外の説明は省かれています。 >>107

[3] ABNF はほとんど RFC 3339 と同じですが、負閏秒への言及が欠けています。

[108] DAV:creationdate は、 date-time を使うと規定されています >>107。

[27] RFC 3339 の出版を待たずに RFC 2518 を出版するため、コピペしたのでしょう (この時代の標準開発では IETF に限らずこのような中長期的な視点を欠いた仕事がしばしば見られました 新規格の先行コピペ )。 RFC 2518 の改訂版である RFC 4918 では当該部分が削除され、 RFC 3339 の date-time が参照されています >>109。

[206] このような方法を採られると、はたして RFC 2518 の規定するものが RFC 3339の日時形式と同じものなのかどうか、 読者が個別に検証しなければならなくなります。

[207] そして先述のような軽微な違いが存在します。 これを同じものと解釈してよいのかどうか、 見解は人によって異なり得ます。 こんなささいな違いから、 情報交換の失敗や大きな不具合につながることがあります。

秒の小数部を認めない変種

[122] SMTP では date-time から秒の小数部を除いたものが使われる場合があります >>121。

[190] JavaScriptのプログラムに渡す時刻の文字列の形式は何が良いか – 或る阿呆の記, 投稿日: 2018年9月11日 投稿者: hackle, [最終更新] 2018年9月12日 () https://hack-le.com/js-date-time-string/#ISO8601RFC3339

この手の話を調べていると、ISO8601ではなくてRFC3339という呼ばれ方をしているものが散見される。「RFC3339 インターネット上の日付と時間:タイムスタンプ」 http://www5d.biglobe.ne.jp/stssk/rfc/rfc3339j.html を読むと、RFC3339は、ISO8601拡張形式をシンプルかつ明示的に再定義したものだ。

文脈的にはほぼ同義のように扱われていることが多いが、RFC3339においてはミリ秒を定義せず、YYYY-mm-ddTHH:MM:SSZの形式であるようだ。自分はこの表記が一番馴染みがある。

[191] このような誤った情報はままみられます。 参照されている 「RFC3339 インターネット上の日付と時間:タイムスタンプ」 は RFC 3339 の和訳で、 本当に「読」んだのであれば秒の小数部が使えることがかなり明確に書かれていることに気づいたはずです。 自分の「馴染み」に引っ張られてしまったのでしょうか。

[268] sigT では

と規定しています。 >>267

IETF の XML 系の変種

[15] IETF の XML 系仕様では XML Schema や RELAX NG のデータ型としては xs:dateTime (XML Schemaの日付形式) を採用しつつ、本文で「RFC 3339 の date-time かつ T と Z は大文字」とされていることが多いです。スキーマが規定か参考かは仕様によりますが、 RFC 3339 と XML Schema の両方の規定の積集合に従わなければならないということになります。 ISO 8601の日付形式 (>>25)に、両者の比較があります。

[6] xs:dateTime は10000年問題に対応していますが、 RFC 3339の日時形式は対応していません。 両方の規定に従うためには、9999年までの年しか扱えません。

[140] RFC 3863 は、 PIDF timestamp 要素を XML Schema では xs:dateTime としながら、 本文では RFC 3339 IMPP datetime format で、 T と Z は大文字と規定しています >>139, >>141。

[142] RFC 3339の日時形式をそのまま使っている RFC 3862 CPIM >>111、 XML Schema で使っている RFC 3863 PIDF >>139、 そして RFC 3339 はいずれも同じ ietf-impp WG で同時期に開発されたものでした。 つまり RFC 3339 の様々なバリエーションの混乱は、はじめから存在していたのです。

[208] あとから新しい要件が発見されてバリエーションが生じたのでなく、 最初からバリエーションがあったとすると、 標準化戦略は最初から間違っていたと言わざるを得ません。

[229] RFC 3923 は PIDF の応用の1つを定めていましたが、 「UTC with no offset」 でなければならないとの追加の制約を規定していました。 >>223

[133] RFC 5070 では、 date-time string は DATETIME data type で表されるとし、 date-time string は RFC 3339 にある ISO 8601 の部分集合で表し、 DATETIME data type は xs:dateTime で実装される >>132 とされています。果たしてこれが何を意味するのかは不明です (RFC 3339の日時形式と xs:dateTime の両方が適用されるという意味でしょうか)。

[135] その改訂版の RFC 7970 では、謎の規定は削除されて、 xs:dateTime だけになっています >>134。

[138] RFC 5388 は、 XML Schema 1.0 第2版 xs:dateTime としながらも、 RFC 3339 の値に制約される >>136、>>137 と規定しています。 両方で共通して認められる値のみ指定可能ということなのでしょうが、 -00:00 がどう扱われるのかは、はっきりしません。

[70] WS-BaseFaults 1.2 は、時間帯が省略された場合には UTC と解釈しなければなりませんと規定しています。

[228] 時間帯の省略は構文上認められていないのですが、 これはエラー処理の規定でしょうか?

Date construct (Atom 1.0)

[48] Atom >>46 および Metalink >>47 では、日時の指定は Date construct と呼ばれています。

[49] Date construct 中には空白を含めてはなりません Atom 1.0 3.。

[50] RFC 3339 の date-time (RFC 3339の日付形式) でなければなりません。 記号 T と Z は大文字でなければなりません。 >>46, >>47

[51] RELAX NG スキーマ (参考) では xsd:dateTime となっています >>46, >>47。

[131] RFC 7049 は、“RFC 4287 3.3 節で refine された RFC 3339 形式” を採用しています >>130。 これに RELAX NG スキーマ (参考) で示された制約まで含まれるのかは不明です。

[218] 「SmartFormat仕様書(Atom準拠)」 は Atom 1.0 とは違う日時形式を規定しています (当然 Atom 1.0 仕様違反)。 SmartFormatの日時形式

[53] Atom 0.3 では W3C-DTF が用いられていました。 Atom 1.0 の定義とほとんど変わりませんが、厳密には多少の違いがあります。
[41] Commit e188b782a1dc1bd8e9e0006fea476b6c92fd04a7 to hakobe's pig - GitHub ( 版) http://github.com/hakobe/pig/commit/e188b782a1dc1bd8e9e0006fea476b6c92fd04a7

Gmailのフィードがhoursが24以上の日付を返してくる

[42] W3C のメーリングリストのアーカイブの Atomフィードは、

    <updated>2014-03-01T11:01:35+0000(UT:C)</updated>
... のようなおかしな日付を出力します。

(RFC 822の日付形式から変換するときに、注釈を考慮せずに時間帯の「:」を補っているようですね・・・。)

EPP

[54] EPP では、 RFC 3339 と XML Schema xsd:dataTime の両方の部分集合である日付形式を規定しています。

[60] RFC 3730〜3733 によれば:

[64] 例:

  • [65] 2000-06-06T22:00:00.0Z
  • [66] 2005-11-26T22:00:00.0Z

UTC 固定の変種

>>222

RFC 5070

[38] RFC 5070 は、 RFC 3339 と xs:dateTime に加えて ISO 8601:2000 にも言及しています。これが適合性と処理にどう影響するのか評価するのは難しいです。 (RFC 3339 も xs:dateTime も ISO 8601 をベースにはしていますが、 細部は違っています。)

[29] RFC 5070 - The Incident Object Description Exchange Format ( 版) https://tools.ietf.org/html/rfc5070#section-2.8

Date-time strings are formatted according to a subset of ISO 8601: 2000 [13] documented in RFC 3339 [12]. The DATETIME data type is implemented as an "xs:dateTime" [3] in the schema.

UTC 固定の変種

[224] RFC 3923 は CPIM メッセージ (message/cpim, >>225) の応用の1つを規定するもので、 「UTC with no offset」 でなければならないとの追加の制約を定めていました。 >>223

[226] Z か z か +00:00 かには特に言及がありません。

[117] RFC 7808 は RFC 3339 date-time の時間帯を Z とするものを UTC date-time値 (UTC date-time value) と呼んでいるようです >>118。

[227] 「use a "Z" suffix, and not fixed numeric offsets」 と説明されており >>118、曖昧ながら Z でも z でも良さそうに読めます。

[222] IETF の XML 系の変種 (>>15) で、更に UTC 限定の制約が付いたものがありました。

[67] RFC 3982 は時間帯を UTC (Z) に固定しています。 (XML Schema 定義では xs:dateTime を使用。)

[69] EPPの日付形式は xs:dataTime と RFC 3339の日付形式の両方の部分集合で、 時間帯を Z に固定した上で T と Z を大文字で記述すると規定しています。 (XML Schema 定義では xs:dateTime を使用。)

Sieve の日時

[125] Sieveの日時形式で iso8601 と呼ばれるものは、 RFC 3339 の date-time に次の制限を加えたものです >>126。

[129] UTC 以外の時差や -00:00 を使うことは禁止されていないようです。 一意性を意識した制約でしょうか。

Syslog の日時

[20] Syslog の TIMESTAMP は RFC 3339の日時形式を採用していますが、 次の制約を加えています >>13。

[203] 負閏秒はどう扱われるのでしょうか。

閏秒のない時刻系

JMAP の日時

[35] JSON Mail Access Protocol Specification (JMAP) ( 版) http://jmap.io/spec.html

Where the API specifies Date as a type, it means a string in RFC3339 date-time format, with the time-offset component always Z (i.e. the date-time MUST be in UTC time) and time-secfrac always omitted. The “T” and “Z” MUST always be upper-case. For example, "2014-10-30T14:12:00Z".

Where the API specifies LocalDate as a type, it means a string in the same format as Date, but with the Z omitted from the end. This only occurs in relation to calendar events. The interpretation in absolute time depends upon the time zone for the event, which MAY not be a fixed offset (for example when daylight saving time occurs).

as2-date-time

[165] Activity Streams 2.0 は RFC 3339 の date-time から派生した as2-date-time を定義しています >>164。

[166] T と Z は、大文字としなければなりません >>164。 (なぜか ABNF 構文では大文字でも小文字でも良いように書かれていますが、 英語では大文字のみ認めています >>164。)

[167] 秒とその直前の : を、省略できます >>164。 ABNF 構文では秒の小数部が存在するときも : と秒の整数部を省略できるとされています >>164。これが意図通りなのかは、はっきりしません。

[169] データ型は xsd:dateTime が使われています >>168。 従って XML Schemaデータ型の制約も適用されるものと思われます。 ただ、 XML Schema の xsd:dateTime では秒の整数部の省略は認められていませんが...

日付のみの変種

[238] RFC 3339 は一般に日時形式を定義していると理解されていますが、 日付形式、時刻形式をも定義しているという解釈もあり得ます (>>87)。 本項に示すのは日付形式を用いた事例です。

[5] RFC 4646 とその改訂版の RFC 5646 は、 IANA登録簿の日付形式として RFC 3339 の full-date を採用しています >>37, >>120。

[33] ( 版) http://www.houjin-bangou.nta.go.jp/documents/k-resource-dl.pdf
凡例凡例の説明
YYYY-MM-DDインターネットの技術標準を議論するIETFによる、RFC3339に則った形式。平成27年10月5日(2015年10月5日)の場合は、「2015-10-05」と設定する。
[239] k-resource-dl.pdf, , https://www.invoice-kohyo.nta.go.jp/download/index.files/k-resource-dl.pdf#page=4
凡例凡例の説明
YYYY-MM-DDインターネットの技術標準を議論するIETFによる、RFC3339に則った形式。 令和3年10月1日(2021年10月1日)の場合は、「2021-10-01」と設定する。

[119] RFC 7808 は RFC 3339 の full-date を参照しています >>118。

tag: URL

[112] tag: URL を規定する RFC 4151 には、次のような規定があります。

[113] RFC 4151 - The 'tag' URI Scheme () https://tools.ietf.org/html/rfc4151

The date is specified using one of the "YYYY", "YYYY-MM" and "YYYY-MM-DD" formats allowed by the ISO 8601 standard [4] (see also RFC 3339 [10]).

[114] この参照をどう解釈するべきなのかは謎過ぎます。なお ISO 8601 は Normative Reference で、 RFC 3339 は Informative Reference です >>113。

I-JSON の変種

[30] RFC 7493 - The I-JSON Message Format ( 版) https://tools.ietf.org/html/rfc7493#section-4.3

It is RECOMMENDED that all such data items be expressed as string values in ISO 8601 format, as specified in [RFC3339], with the additional restrictions that uppercase rather than lowercase letters be used, that the timezone be included not defaulted, and that optional trailing seconds be included even when their value is "00". It is also RECOMMENDED that all data items containing time durations conform to the "duration" production in Appendix A of RFC 3339, with the same additional restrictions.

[36] RFC 3339 では秒はそもそも省略可能ではないのだが。

TOML の変種

[171] TOMLの日時形式は RFC 3339 をベースにしたもので、4種類あります。 いずれも TOML で使われます。

[172] Offset Date-Time は、 時間の特定の瞬間を表すものです。 RFC 3339 date-time で、時差が指定されたものです。 >>170

[174] Local Date-Time は、時差・時間帯を記述せずに特定の日時を表すものです。 RFC 3339 date-time で、時差を省いたものです。 >>170

[175] 追加の情報がないと特定の瞬間に変換することはできず、その必要が生じた場合の方法は実装規定です。 >>170

[177] Local Time は、日、時差・時間帯を記述せずに日の時刻を表すものです。 RFC 3339 date-time の時刻部分のみを使ったものです。 >>170

[173] これら3つの形式において、秒の小数部の精度は実装規定としますが、 最低でもミリ秒精度を持つことが期待されます。 実装が扱える精度よりも細かい値が与えられた時、 丸めるのではなく、切り捨てなければなりません。 >>170

[176] Local Date は、時差・時間帯を記述せずに特定の日の全体を表すものです。 RFC 3339 date-time の日付部分のみを使ったものです。 >>170

MongoDB の変種

[255] MongoDB Extended JSON (v2) の Date は RFC 3339の日時形式のプロファイルを規定しています。 次の制約があります。 MongoDB Extended JSONにおける日時

関連

ISO 8601 との関係

[7] RFC 3339 の日付・時刻形式は、 ISO 8601の日付形式の部分集合です (一部怪しいですが)。 基本的に RFC 3339 形式の日時は、 ISO 8601 形式の日時でもあります。 逆は必ずしも真ではありません。

[16] ISO 8601の日付形式 (>>25)に、類似形式との比較があります。

[88] RFC 3339 には、 (なぜか) RFC 3339 で採用しなかった部分を含む ABNF 構文が収録されています。 ISO 8601の日時形式

[195] RFC 3339 形式の日時を、 「ISO 8601 形式の日時である」 というのは正しいです。 RFC 3339 形式に対応することを、「ISO 8601 形式に対応する」 というのは不正確で誤解を招く表現なので、避けるべきです。

[209] 「ISO 8601 (RFC 3339) 形式」 という言い方も、少なくないようです。 ISO 8601 のうち RFC 3339 部分、 というのをこう書くことは、 理論上は間違ってはいません。 しかしこの書き方は ISO 8601 の別称が RFC 3339 とも解せます。 他にもいろいろ解釈のしようがあります。 敢えて紛らわしい ISO 8601 を併記する意味がわかりません。 誤解を招くだけの表現なので、避けるべきです。

[210] 正しく理解していない人が、目についた名前を適当に書いているだけのきらいもあります。 だとすると、このような表現を使った解説は信用できない可能性が高い、 というヒントになるかもしれません。

HTML との関係

[9] HTMLの日付形式 (大域日時) と似ていますが、 HTML では T や Z に大文字を使わなければなりませんし、 HTML は閏秒にも対応していません。

[45] HTML が RFC 3339の日時形式を採用したことは一度もありません。

[52] RFC 3339 が特別な解釈を与えた値 (-00:00) を禁止している >>71 ソースコードのコメント参照 ように、関係性を意識はしていますが、 それは互換性を求める存在というよりは区別されるべき存在としてでしょう。

[72] ところが、一部で HTML の日時が RFC 3339 形式であるとのデマが流布されたことがあるようです。 しかもその元をたどると、 (当時まだ WHATWG と協力関係にあった) W3C の HTML WG の HTML: The Markup Language という文書でした。 /TR/ で出版された最初の版に既に RFC 3339 形式を制限したものだとの記載 >>73 があり、 /TR/ で出版された最後の版ではそれが“拡充”されていました >>74, >>75。

[76] この文書は、著者向けを謳って HTML 5 本体仕様の内容を説明しなおしたものでしたが、 当時から技術的内容が異なる可能性が指摘され、存在意義に疑問を持たれていました。 実際、本来の規定と異なる内容を「著者向けにわかりやすく」公式に説明することで、 デマを拡散してしまったわけです。 (危惧が現実化したことまで当時把握していたかどうかは不明ですが、 この文書は結局未完成のまま破棄されました。落ち着くべきところに落ち着いたのは良かったですが...)

[77] そもそもなぜこの文書が RFC 3339 を参照していたのかは、謎です。 HTML 5 を読まずに書いたわけではないでしょうし。。。

日付処理

歴史

[43] draft-newman-datetime-01 - Date and Time on the Internet () https://tools.ietf.org/html/draft-newman-datetime-01

[40] draft-ietf-impp-datetime-00 - Date and Time on the Internet: Timestamps () https://tools.ietf.org/html/draft-ietf-impp-datetime-00

[143] W3C-DTF には、 RFC 3339 の前の I-D の影響を受けた旨が記載されています。

PICS の日時形式

[158] PICS は RFC 3339 の前の I-D を参照しつつも、 独自の日時形式を規定していました。

[161] ものによっては日付の区切りに - ではなく . を使っています >>160。

[214] DRAFT-PICS-services-970620 () https://www.w3.org/PICS/Member/NG/DRAFT-PICS-services-970620.html#Semantics

If not specified, it defaults to "0000-00-00T00:01-0000". If specified, tools that construct profiles may utilize this information in a slider bar or pulldown list. The sign and timezone have no meaning when used with increment, and the MM value may have 00. Typical values are:

"0001-00-00T00:00-0000" meaning "one year";

"0000-01-00T00:00-0000" meaning "one month";

"0000-00-01T00:00-0000" meaning "one day";

"0000-00-00T01:00-0000" meaning "one hour";

"0000-00-00T00:01-0000" meaning "one minute"

[10] Web Applications 1.0 r5474 disallow -00:00 in a global date and time stringFixing http://www.w3.org/Bugs/Public/show_bug.cgi?id=10370 ( ( 版)) http://html5.org/tools/web-apps-tracker?from=5473&to=5474

[148] レシートのフィールド () https://developer.apple.com/jp/documentation/General/ValidateAppStoreReceipt/Chapters/ReceiptFields.html

IA5STRING(RFC 3339の日付として解釈されます)

[149] Amazon CloudSearch での日付と時刻の検索 - Amazon CloudSearch () http://docs.aws.amazon.com/ja_jp/cloudsearch/latest/developerguide/searching-dates.html

日付と時刻は、IETF RFC3339: yyyy-mm-ddTHH:mm:ss.SSSZ に従って、UTC(協定世界時間)で指定されます。たとえば、1970 年 8 月 23 日午後 5 時は、UTC 形式では 1970-08-23T17:00:00Z となります。UTC で時間を指定するときは、小数点以下の秒数も指定できます。例: 1967-01-31T23:20:50.650Z.

[150] WjInputTime Class - Wijmo 5 Help () http://wijmo.com/5/docs/topic/wijmo.angular.WjInputTime.Class.html

If provided, the min and max attributes are strings in the format "hh:mm". Technically, you can use any full date as defined in the W3C [RFC 3339], which is also the format used with regular HTML5 input elements.

[151] WjInputTime クラス - Wijmo 5 Help () http://wijmo.c1.grapecity.com/5/docs/topic/wijmo.angular.WjInputTime.Class.html

min属性とmax属性を指定する場合、それらは書式"hh:mm"の文字列にする必要があります。技術的には、W3Cの[RFC 3339]で定義されている任意の日時を使用できます。これは、標準HTML5入力要素でも使用される書式です。

[152] なぜか RFC 3339 は W3C が定義したことになっている。 そしてそれは HTML5 input で使えることになっている (>>45 にある通り、デマ)。 この説明と例示には「hh:mm」の時刻が示されているのだが、 RFC 3339 で定義された「any full date」が使えるという。 (実装上どちらが正しいのかは知らぬ。) 「any full date」とは何か。そもそも「hh:mm」は「any full date」 に含まれるのか、それともどちらも使えるという意味なのか。 RFC 3339 にある full-date と関係あるのかどうか。 日本語訳では「任意の日時」となっている。日時、日付、時刻は厳密に使い分けられないことも多々あるが、 この文脈でこういう書き方をされると、何を意図しているのかさっぱりわからなくなる。

[153] SVF PDF Archiver Web APIリファレンス () https://manual.wingarc-support.com/manual/svf/spa93apiref/?pageId=p55980886

ISO8601 RFC3339 W3CDTF(日付と時刻をTでつなげる)に準拠した文字列(例 "2016-11-22T11:18:43.933+0900")で出力します。

[154] Introduction · TRUST DOCK (Trustdock著, ) https://docs.trustdock.io/ja/

String(RFC3339で定義されているfull-dateに準ずる)

[155] Introduction · TRUST DOCK (Trustdock著, ) https://docs.trustdock.io/ja/

String(RFC3339で定義されているdate-timeに準ずる)

[156] イベント(グループ) — サイボウズ Live・API ドキュメント () https://developer.cybozulive.com/doc/current/pub/gwSchedule.html

フォーマットは RFC 3339 の日時表現でなければなりません。

[157] People Finder Interchange Format 1.4 ( ()) https://www.oasis-open.org/committees/download.php/49618/

All dates and times must be in UTC, never in a local time zone, because data records will be transmitted among many different time zones. This format uses dates in the RFC 3339 format, with only UTC allowed. Front-ends can convert dates and times to the local time zone for display.

[178] RFC 5323 - Web Distributed Authoring and Versioning (WebDAV) SEARCH () https://tools.ietf.org/html/rfc5323#section-5.10

when operand for a comparison with a DAV:creationdate or DAV:

getlastmodified property, it SHOULD be treated as a date value in

the ISO-8601 subset defined for the DAV:creationdate property (see

Section 15.1 of [RFC4918]; the behavior of values not in this

format is undefined),

[179] Concise Binary Object Representation (CBOR) () https://cbor-wg.github.io/CBORbis/#datetimesect

Tag value 0 is for date/time strings that follow the standard format described in [RFC3339], as refined by Section 3.3 of [RFC4287].

[180] Language Guide (proto3)  |  Protocol Buffers  |  Google Developers () https://developers.google.com/protocol-buffers/docs/proto3

Uses RFC 3339, where generated output will always be Z-normalized and uses 0, 3, 6 or 9 fractional digits. Offsets other than "Z" are also accepted.

[189] dateTime reference when mapping to JSON types [I18N] · Issue #641 · w3c/wot-thing-description () https://github.com/w3c/wot-thing-description/issues/641

[193] REST リソース: urlNotifications  |  検索  |  Google Developers () https://developers.google.com/search/apis/indexing-api/v3/reference/indexing/rest/v3/urlNotifications

RFC3339 UTC「Zulu」形式のタイムスタンプ。精度はナノ秒。例: "2014-10-02T15:01:23.045123456Z"

[194] Google: google_data_fusion_instance - Terraform by HashiCorp () https://www.terraform.io/docs/providers/google/r/data_fusion_instance.html

create_time - The time the instance was created in RFC3339 UTC "Zulu" format, accurate to nanoseconds.

[217] JSON Feed - JSON Feed Version 1.1 (, ) https://jsonfeed.org/version/1.1#items

[219] [tz] make rearguard_tarballs fails on macOS (, ) https://mm.icann.org/pipermail/tz/2020-October/029362.html

[230] draft-ryzokuken-datetime-extended-02, https://datatracker.ietf.org/doc/html/draft-ryzokuken-datetime-extended-02

[231] CACAO Security Playbooks Version 1.0 (, ) https://docs.oasis-open.org/cacao/security-playbooks/v1.0/cs01/security-playbooks-v1.0-cs01.html#_xl5n20qrhhr5

[232] draft-ietf-sedate-datetime-extended-00, https://datatracker.ietf.org/doc/html/draft-ietf-sedate-datetime-extended

[233] sedate, https://mailarchive.ietf.org/arch/browse/sedate/

[234] IAB Minutes 2021-08-25 | Internet Architecture Board, https://www.iab.org/documents/minutes/minutes-2021/iab-minutes-2021-08-25/

[236] Serialising Extended Data About Times and Events (sedate) -, https://datatracker.ietf.org/wg/sedate/about/

[235] Minutes IETF111: sedate, https://datatracker.ietf.org/doc/minutes-111-sedate/

Updated: