[12] 本項では、インターネットの電子メールおよび派生仕様において用いられている日時形式を説明します。 電子メール (RFC 822) の日時形式は、後に RFC 3339 が出版されるまで、 インターネットの標準的な日時の表現形式とみなされてきました。 そのため電子メール以外でも多くのプロトコルでこの形式が採用されました。
[145] この日時形式は元々人間の読み書きと機械的な読み書きの両方が想定された折衷的な形式で、 なおかつ自由度も高かったため、非標準なものも含め様々なバリエーションがありました。 時代が下るにつれ相互運用性や実装の簡便性への関心の高まりから、 各プロトコルでそれぞれの事情に合わせた制約が追加されていきました。
[68] 電子メールの日時形式の歴史は長いですが、実用上は 1982年の RFC 822 (>>13) 以降を考慮すれば十分です。 RFC 822 が最も緩い (自由度の高い) 構文を定義しており、 時代が進むにつれ、より限定的な構文へと変化してきています。
[63] RFC 822 (>>13) は、長らくインターネットの電子メールの標準仕様となっていました。 RFC 822 のメッセージ形式は、電子メールのみならず、USENET 系ネットニュースに使われたり、 派生形が HTTP その他のプロトコルで採用されたり、 インターネットの多くのプロトコルに影響を与えました。 RFC 822 の定義する日時形式も、 HTTPの日付形式の一つとして採用されたり、 RSS など電子メールと直接関係しないプロトコルに採用されるなどして広く用いられました。
[64] RFC 1123 (>>44) は RFC 822 の一部を改訂するものです。 RFC 822 の日時形式というとき、 多くの場合はこの改訂を経たものを指していますが、他の RFC による部分改訂という (IETF ではよく見られるものの、外部からは) わかりにくい形を採っているためか、 明示的に引用されていないことがあります。
[73] 電子メールの関連仕様である RFC 2183 (>>61) は、 RFC 822 の日時形式のプロファイルを用いています。
[65] 電子メールの関連仕様である RFC 1894 (>>72)、RFC 2852 (>>71)、 RFC 3464 (>>70) は、RFC 1123 の日時形式のプロファイルを用いています。
[78] 2001年の RFC 2822 (>>77) は RFC 822 の全面改訂です。日時形式に関しても、 RFC 822 + RFC 1123 の構文に対して大きな制約を加えています。 RFC としては 2822 は 822 を廃止して置き換えるものですが、 IETF の手続き上の理由により、インターネット標準としては RFC 822 が引き続き (形式的に) 存続しています。 RFC 822 の圧倒的な知名度から、 2822 の出版以後も RFC 以外からは RFC 822 が参照され続けています。 RFC 5322 (>>106) は RFC 2822 を廃止し、置き換える小改訂です。
[14] 「曜日(英略), 日 月(英略) 年 時:分:秒 時間帯」という形式です。 このうち、曜日と秒は省略可能です。
[58] RFC 822 の message 例中に登場する日付 「27 Aug 76 0932 PDT」 は時・分の間に「:」が入らない RFC 733 以前の書き方で、 不適当です。
[40] RFC 822 では字句間 (構成要素や記号の間) に linear-white-space
や comment
を自由に挿入して良いとされていました。
[53] 例えば、
Wed (= Wednesday), 15 (th) Mar (March = 3rd month of year) 2002 12 (hour):32 (minute):23 (second) (timezone =) +0900 (JST)
という書き方も RFC 1123 時代には認められていました。
... に FWS を要求しています。また、
... には FWS を認めていますが、なくても構いません。更に、
... には CFWS を認めています。いずれにせよ、 FWS は U+0020
1つとすることが推奨されています。 >>77 3.3., >>106 3.3.
[95] RFC 2822/RFC 5322 は生成については >>79 のようにしなければならないとしていますが、 RFC 822 が認めていたとおり、任意の字句間の CFWS を理解できなければならないともしています >>94 4.3., >>106 4.3.。
comment
の定義は RFC 822
と RFC 2822/RFC 5322 で厳密には異なります。詳しくはそれぞれの項を参照してください。[104] RFC 822/RFC 2822/RFC 5322 では注釈に使える文字は ASCII のみですが、 RFC 5335/RFC 6532 は U+0080-U+10FFFF も更に認めています。
[133] son-of-RFC 1036 は、自由な CFWS の挿入は認めず、後に RFC 2822 によって FWS
が必須とされる場所で空白を要求していました。 son-of-RFC 1036 では空白として
U+0020
と U+0009
の1文字以上の列を認めています >>117 4.1. が、
U+0020
を使うべきともされていました。 >>117 4.2.3.
[15] 曜日は、英語の3文字省略形である次のいずれかを用いることになっています >>13 5.1., >>77 3.3., >>106 3.3., >>117 5.1.。
[16] 大文字と小文字は区別しません >>13 3.4.7.。
[76] sylpheed は曜日名の大文字・小文字が違っていると認識に失敗するそうです。 他にもこんな MUA があるかもしれません。
[31] 曜日とその直後の ,
は、省略できます >>13 5.1., >>77 3.3., >>106 3.3.。
[33] 曜日と日は整合していなければなりません >>13 5.2., >>77 3.3., >>106 3.3., >>117 5.1.。
[17] 日は、1桁または2桁の数字で表すことになっています >>13 5.1., >>77 3.3., >>117 5.1.。
[36] RFC 822 は日の範囲を正確には定義していませんが、 son-of-RFC 1036 と RFC 2822/RFC 5322 は正しい値であることを要求しています >>77 3.3., >>117 5.1.。
[18] 月は、英語の3文字省略形である次のいずれかを用いることになっています >>13 5.1., >>117 5.1.。
[20] RFC 822 は、年を2桁の数字で表すとしていました >>13 5.1.。
[37] RFC 1123 は RFC 822 の >>20 の規定を改め、 2桁から4桁までの年を認めています >>44 5.2.14。
[50] RFC 1123 は 4桁の年を生成するべき >>44 5.2.14 としていました。
[51] RFC 1123 は2桁の年をどう解釈するべきかは定義していません。
[52] RFC 1123 は副作用として3桁の年も認めていますが、それにはまったく言及していません。 どう解釈するべきかは不明です。
[66] RFC 2183 は RFC 822 の日時形式を採用しており、 RFC 1123 にはまったく言及していませんが、例示では4桁の年が用いられています。
[118] son-of-RFC 1036 は2桁または4桁の年を認めていました。 ただし4桁にするべきとされていました。 2桁は、1900年代と解釈しなければなりません。 >>117 5.1.
[86] RFC 2822/RFC 5322 は、4桁以上の年を認めています >>77 3.3., >>106 3.3.。
[89] RFC 2822/RFC 5322 では、年は (構文上の制限はありませんが) 1900年かそれ以降とされています >>77 3.3., >>106 3.3.。
[96] RFC 2822/RFC 5322 では、生成は認められていませんが、 2桁、3桁の年を理解することは要求されています。 2桁の年は、1950年から2049年の範囲と解釈しなければなりません。 3桁の年は、1900を足して解釈しなければなりません。 >>94 4.3., >>106 4.3.
[141] VPIMv2 を規定する RFC 3801 は2004年に出版されたにも関わらず、 2桁年号の例を示しています >>48。
[21] 時は、2桁の数字で表すことになっています >>13 5.1., >>77 3.3., >>106 3.3., >>117 5.1.。
[25] 範囲は 00 から 23 までとされています >>13 5.1., >>77 3.3., >>106 3.3., >>117 5.1.。
[22] 分は、2桁の数字で表すことになっています >>13 5.1., >>77 3.3., >>106 3.3., >>117 5.1.。
[26] 範囲は 00 から 59 までとされています >>13 5.1., >>77 3.3., >>106 3.3., >>117 5.1.。
[23] 秒は、2桁の数字で表すことになっています >>13 5.1., >>77 3.3., >>106 3.3., >>117 5.1.。
[24] 秒とその直前の :
は、省略できます >>13 5.1, >>77 3.3., >>106 3.3., >>117 5.1.。
[27] RFC 822 では範囲は 00 から 59 までとされています >>13 5.1.。 従って正閏秒は表現できません。
[92] RFC 2822/RFC 5322 と son-of-RFC 1036 では範囲は 00 から 60 までとされており、 閏秒も反映されることになっています >>77 3.3., >>106 3.3., >>117 5.1.。
[28] インターネットメールの時間帯表記を参照。
[110] USENET 系ネットニュースは、電子メールではありませんが、 RFC 822 のメッセージ形式を採用しています。ただし、 RFC 822 より構文が限定的になっている他、 USENET 独自の歴史的経緯により、実装上電子メールとは異なる配慮が必要なこともあります。
[111] ネットニュースについては RFC 1036 が長らく標準仕様と考えられてきました。 RFC 1036 は、 RFC 822 の定義に従い USENET のソフトウェアの getdate(3) が認識できる書式を用いることを要求しています >>109。具体的には記述されていませんが、
Wdy, DD Mon YY HH:MM:SS TIMEZONE... がそのような書式の1つである >>109 とされています。
[112] 一般にネットニュースでは CFWS の自由の挿入は認められていないと考えられていました。
[113] 更に RFC 1036 は ctime(3) 形式の
Wdy Mon DD HH:MM:SS YYYY... は RFC 822 に適合しないため認められないものの、用いられているため、対応するのが良い >>109 としていました。
[131] RFC 1036 に変わって事実上の標準とみなされるようになった son-of-RFC 1036 は、より明確な定義を含んでおり (本項の他の部分で説明しています)、 >>113 のような推奨も含まれなくなっています。
[136] RFC 1036 と son-of-RFC 1036 にかわって (ネットニュースが絶滅に近い状態になった)
2009年に出版された RFC 5536 は、 GMT
の扱いを除き、 RFC 5322
を完全に参照しています >>135, >>144。
[4] RSS 2.0 は (仕様書内で一貫していない部分もありますが) RFC 822 の日付形式を採用し、 年号は4桁でもよく、4桁が望ましいとしています >>139。
[140] RSS 2.0 文書に関して、 RSS Best Practices Profile は次のようなことを述べています >>5。
Z
以外の1文字時間帯文字列は使用するべきではありません。GMT
、+0000
、-0000
のみです。[6] 現実の RSS 文書の日付は RFC 822 に適合していないことがあります。 例えば、時が1桁だったりします。
[3]
OPML は RFC 822の日付形式を採用しているとしています。
しかし、実例では4桁年号が用いられています。
実装が2桁年号や comment
に対応しているのかは謎です。
[32] SmartFormat (「RSS2.0準拠」を称するが RSS 2.0 とは互換性がない) の日時形式。
[30] SmartFormat仕様書(RSS2.0準拠) – SmartNews 媒体運営者サポートサイト, https://publishers.smartnews.com/hc/ja/articles/360010977813
フォーマットは RFC822 に定められたものする
RSS 2.0 ではなく RFC 822 を参照。 本文ではまた別の説明。
[38] SmartFormat (「Atom準拠」を称するが Atom 1.0 とは互換性がない) の日時形式。 Atom 本来の形式の説明と RSS 2.0の日時形式系統の説明が混在。 (実装がどうなっているのか不明。)
[34] SmartFormat仕様書(Atom準拠) – SmartNews 媒体運営者サポートサイト, https://publishers.smartnews.com/hc/ja/articles/360010977833#feed-updated
[42] Atom 1.0の日時形式は W3C-DTF とは異なる。この実装は仕様違反。
[115] こんな技術的レベルが低くても SmartNews というスマートフォンアプリは普及しているのでこの形式もよく使われていると推測される。 技術レベルの高い低いと市場で成功するかどうかは無関係だとよくわかる。 不幸中の幸いなのは、この形式を処理するのは SmartNews 社内システムだけなので、 外部の一般の技術者はこの形式をどう扱うか考えなくてすむこと。 ただし社外の一般の技術者もこの形式で生成しなければならない場面はある。
[35] RFC 2183の日時形式は次の場面で使われています。
[143] RFC 5322の日時形式は RFC 5547 が規定する SDP の属性でも使われています。
[88] RFC 821 - Simple Mail Transfer Protocol, , https://tools.ietf.org/html/rfc821#page-33
[154] RFC 3339 は RFC 2822の日時形式を Email Date/Time Format と呼んでいます >>153。
[108] RFC 822 の前の世代の RFC 733の日付形式は、また異なるものでした。
[46] RFC 2822の日付形式は RFC 822 + RFC 1123 の形式を再定義したものです。
[47] RFC 1505の日時形式は、 RFC 822 と似ていますが、異なるものでした。
[75] RFC 2822 の日付形式は Internet の標準的な日付表現形式として、 RFC 2822 メッセージ以外でもよく使われてきましたが、 IETF は ISO 8601 に基づいた新しい RFC 3339の日付形式を提案標準として発表しました。 今後の新しい IETF protocol はこの形式に則って規定されることになります。 また、それ以外の仕様や実装でもこの新しい標準を採用するのが良いでしょう。
[69] RFC 4865 は SMTP と DSN を拡張するものですが、 RFC 3339の日付形式を採用しています。
[101] mbox は ctime 形式を採用しています。
[1] 1993年の調査では半分くらいのメッセージが4桁年号に移行していたとか。 (RFC 1123 は1989年。) 時間帯は数値指定も多いものの文字列指定のほうが圧倒的ですかね。非標準名もよく見かけます。
[2] 2003-01-25 14:07 >>1: 今でも文字列名の時間帯はたまに見かけますね。2桁年号とか、秒指定がないのとかはもう何年も見ていませんが。
[146] Twilio Doc - REST API ( 版) https://jp.twilio.com/docs/api/rest
[149] IETF が差分仕様書というわかりにくい形で仕様を改訂し、 日時処理ライブラリーの開発者がなぜか元の RFC 822 形式を実装し、 ドキュメントに何を選ぶのが正しいか明確に記述しなかった、 という不幸が重なり事情を知らない開発者が混乱し、 結果ゴミデータが蔓延する、とかいう悲劇が21世紀になって10年経っても未だに続いているとかわらえない。
[155] RFC 5260 - Sieve Email Filtering: Date and Index Extensions () https://tools.ietf.org/html/rfc5260
[97] RFC Errata Report » RFC Editor, https://www.rfc-editor.org/errata_search.php?rfc=3297