376.txt

[12] 本項では、[[インターネット]]の[[電子メール]]および派生仕様において用いられている[[日時形式]]を説明します。

* 仕様書

[REFS[
- [13] [CITE@en[RFC 822 - STANDARD FOR THE FORMAT OF ARPA INTERNET TEXT MESSAGES]] ([TIME[2014-03-08 23:19:55 +09:00]] 版) <http://tools.ietf.org/html/rfc822#section-5>
- [44] [CITE@en[RFC 1123 - Requirements for Internet Hosts - Application and Support]] ([TIME[2014-03-19 20:00:09 +09:00]] 版) <http://tools.ietf.org/html/rfc1123#page-55>
- [106] [CITE@en[RFC 5322 - Internet Message Format]] ([TIME[2014-05-13 12:04:08 +09:00]] 版) <http://tools.ietf.org/html/rfc5322#section-3.3>
-- [77] 旧版 [CITE@en[RFC 2822 - Internet Message Format]] ([TIME[2014-03-08 23:10:45 +09:00]] 版) <http://tools.ietf.org/html/rfc2822#section-3.3>
-- [94] 旧版 [CITE@en[RFC 2822 - Internet Message Format]] ([TIME[2014-03-08 23:10:45 +09:00]] 版) <http://tools.ietf.org/html/rfc2822#section-4.3>
- [61] [CITE@en[RFC 2183 - Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field]] ([TIME[2014-03-30 00:22:36 +09:00]] 版) <http://tools.ietf.org/html/rfc2183>
- [70] [CITE@en[RFC 3464 - An Extensible Message Format for Delivery Status Notifications]] ([TIME[2014-02-09 11:19:25 +09:00]] 版) <http://tools.ietf.org/html/rfc3464>
-- [72] 旧版 [CITE@en[RFC 1894 - An Extensible Message Format for Delivery Status Notifications]] ([TIME[2014-03-09 10:00:41 +09:00]] 版) <http://tools.ietf.org/html/rfc1894>
- [71] [CITE@en[RFC 2852 - Deliver By SMTP Service Extension]] ([TIME[2014-04-20 15:19:04 +09:00]] 版) <http://tools.ietf.org/html/rfc2852#section-5>
]REFS]

[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]] による部分改訂という
[WEAK[([[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]] を廃止し、置き換える小改訂です。

[REFS[
- [109] [CITE@en[RFC 1036 - Standard for interchange of USENET messages]] ([TIME[2014-03-09 00:13:00 +09:00]] 版) <http://tools.ietf.org/html/rfc1036#section-2.1.2>
- [117] [CITE@en[RFC 1849]] ([TIME[2014-03-09 17:56:58 +09:00]] 版) <http://tools.ietf.org/html/rfc1849#section-5.1>
- [135] [CITE@en[RFC 5536 - Netnews Article Format]] ([TIME[2014-03-09 09:57:58 +09:00]] 版) <http://tools.ietf.org/html/rfc5536#section-3.1.1>
]REFS]

[REFS[
- [139] [CITE[RSS 2.0 Specification]] ([CODE[2007-01-03 19:03:10 +09:00]] 版) <http://blogs.law.harvard.edu/tech/rss>
- [5] [CITE@en[RSS Best Practices Profile]] ([CODE[2008-10-23 18:58:35 +09:00]] 版) <http://www.rssboard.org/rss-profile-1#data-types-datetime>
]REFS]

;; [74] [[HTTP]] における[[日時形式]]については、本項ではなく、[[HTTPの日付形式]]を参照してください。

* 構文

[14] 「曜日(英略), 日 月(英略) 年 時:分:秒 時間帯」という形式です。
このうち、曜日と秒は省略可能です。

[58] [[RFC 822]] の message 例中に登場する日付 「27 Aug 76 0932 PDT」
は時・分の間に「:」が入らない [[RFC 733]] 以前の書き方で、
不適当です。

* 空白と注釈

[40] [[RFC 822]] では[[字句]]間 (構成要素や記号の間) に [CODE(ABNF)@en[[[linear-white-space]]]]
や [CODE(ABNF)@en[[[comment]]]] を自由に挿入して良いとされていました。

;; [41] 詳しくはそれぞれの項を参照してください。

[EG[
[53] 例えば、
[PRE[
  Wed (= Wednesday), 15 (th) Mar (March = 3rd month of year) 2002
    12 (hour):32 (minute):23 (second) (timezone =) +0900 (JST)
]PRE]

という書き方も [[RFC 1123]] 時代には認められていました。
]EG]

[79] [[RFC 2822]]/[[RFC 5322]] は、
- [80] [[日]]と[[月]]の間
- [81] [[月]]と[[年]]の間
- [82] [[時刻]]と[[時差]]の間

... に [[FWS]] を要求しています。また、
- [83] 先頭
- [84] [CODE[[[,]]]] と[[日]]の間

... には [[FWS]] を認めていますが、なくても構いません。更に、
- [85] 末尾

... には [[CFWS]] を認めています。いずれにせよ、 [[FWS]] は [CODE[[[U+0020]]]]
1つとすることが[['''推奨''']]されています。 [SRC[>>77 3.3., >>106 3.3.]]

[95] [[RFC 2822]]/[[RFC 5322]] は生成については >>79 のようにしなければ[['''ならない''']]としていますが、
[[RFC 822]] が認めていたとおり、任意の[[字句]]間の [[CFWS]] を理解できなければ[['''ならない''']]ともしています
[SRC[>>94 4.3., >>106 4.3.]]。

;; [103] [[linear-white-space]] = [[FWS]] と [CODE(ABNF)@en[[[comment]]]] の定義は [[RFC 822]]
と [[RFC 2822]]/[[RFC 5322]] で厳密には異なります。詳しくはそれぞれの項を参照してください。

[104] [[RFC 822]]/[[RFC 2822]]/[[RFC 5322]] では[[注釈]]に使える[[文字]]は [[ASCII]] のみですが、
[[RFC 5335]]/[[RFC 6532]] は [[U+0080]]-[[U+10FFFF]] も更に認めています。

;; [105] 詳しくは [CODE(ABNF)@en[[[comment]]]] を参照してください。

[133] [[son-of-RFC 1036]] は、自由な [[CFWS]] の挿入は認めず、後に [[RFC 2822]] によって [[FWS]] 
が必須とされる場所で[[空白]]を要求していました。 [[son-of-RFC 1036]] では[[空白]]として
[CODE[[[U+0020]]]] と [CODE[[[U+0009]]]] の1文字以上の列を認めています [SRC[>>117 4.1.]] が、
[CODE[[[U+0020]]]] を使う[['''べき''']]ともされていました。 [SRC[>>117 4.2.3.]]

;; [134] 後述の通り、[[時間帯]]の名前としての[[注釈]]のみ認めていました。

* 曜日

[15] [[曜日]]は、[[英語]]の3文字省略形である次のいずれかを用いることになっています
[SRC[>>13 5.1., >>77 3.3., >>106 3.3., >>117 5.1.]]。

[FIG[
- [CODE[[[Mon]]]]
- [CODE[[[Tue]]]]
- [CODE[[[Wed]]]]
- [CODE[[[Thu]]]]
- [CODE[[[Fri]]]]
- [CODE[[[Sat]]]]
- [CODE[[[Sun]]]]
]FIG]

[16] [[大文字]]と[[小文字]]は区別しません [SRC[>>13 3.4.7.]]。

[76] [[sylpheed]] は曜日名の大文字・小文字が違っていると認識に失敗するそうです。
他にもこんな [[MUA]] があるかもしれません。

[31] [[曜日]]とその直後の [CODE[[[,]]]] は、省略できます [SRC[>>13 5.1., >>77 3.3., >>106 3.3.]]。

[33] [[曜日]]と[[日]]は整合していなければなりません [SRC[>>13 5.2., >>77 3.3., >>106 3.3., >>117 5.1.]]。

* 日

[17] [[日]]は、1桁または2桁の[[数字]]で表すことになっています [SRC[>>13 5.1., >>77 3.3., >>117 5.1.]]。

[36] [[RFC 822]] は[[日]]の範囲を正確には定義していませんが、
[[son-of-RFC 1036]] と [[RFC 2822]]/[[RFC 5322]] は正しい値であることを要求しています [SRC[>>77 3.3., >>117 5.1.]]。

* 月

[18] [[月]]は、[[英語]]の3文字省略形である次のいずれかを用いることになっています [SRC[>>13 5.1., >>117 5.1.]]。

[FIG[
- [CODE[[[Jan]]]]
- [CODE[[[Feb]]]]
- [CODE[[[Mar]]]]
- [CODE[[[Apr]]]]
- [CODE[[[May]]]]
- [CODE[[[Jun]]]]
- [CODE[[[Jul]]]]
- [CODE[[[Aug]]]]
- [CODE[[[Sep]]]]
- [CODE[[[Oct]]]]
- [CODE[[[Nov]]]]
- [CODE[[[Dec]]]]
]FIG]

[19] [[大文字]]と[[小文字]]は区別しません [SRC[>>13 3.4.7.]]。

* 年

[20] [[RFC 822]] は、[[年]]を2桁の[[数字]]で表すとしていました [SRC[>>13 5.1.]]。

[37] [[RFC 1123]] は [[RFC 822]] の >>20 の規定を改め、
2桁から4桁までの[[年]]を認めています [SRC[>>44 5.2.14]]。

;; [49] ちなみに、なぜか RFC 822 の前の世代の[[RFC733の日付形式]]では
4桁も OK になっていました。

[50] [[RFC 1123]] は 4桁の[[年]]を生成する[['''べき''']] [SRC[>>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年代と解釈しなければ[['''なりません''']]。 [SRC[>>117 5.1.]]

[86] [[RFC 2822]]/[[RFC 5322]] は、4桁以上の[[年]]を認めています [SRC[>>77 3.3., >>106 3.3.]]。

[89] [[RFC 2822]]/[[RFC 5322]] では、[[年]]は (構文上の制限はありませんが) [[1900年]]かそれ以降とされています
[SRC[>>77 3.3., >>106 3.3.]]。

[96] [[RFC 2822]]/[[RFC 5322]] では、生成は認められていませんが、
2桁、3桁の[[年]]を理解することは要求されています。
2桁の[[年]]は、1950年から2049年の範囲と解釈しなければ[['''なりません''']]。
3桁の[[年]]は、1900を足して解釈しなければ[['''なりません''']]。 [SRC[>>94 4.3., >>106 4.3.]]

;; [119] [[son-of-RFC 1036]] と [[RFC 2822]]/[[RFC 5322]] で、00年から49年までの解釈が異なります。

* 時

[21] [[時]]は、2桁の[[数字]]で表すことになっています [SRC[>>13 5.1., >>77 3.3., >>106 3.3., >>117 5.1.]]。

[25] 範囲は 00 から 23 までとされています [SRC[>>13 5.1., >>77 3.3., >>106 3.3., >>117 5.1.]]。

* 分

[22] [[分]]は、2桁の[[数字]]で表すことになっています [SRC[>>13 5.1., >>77 3.3., >>106 3.3., >>117 5.1.]]。

[26] 範囲は 00 から 59 までとされています [SRC[>>13 5.1., >>77 3.3., >>106 3.3., >>117 5.1.]]。

* 秒

[23] [[秒]]は、2桁の[[数字]]で表すことになっています [SRC[>>13 5.1., >>77 3.3., >>106 3.3., >>117 5.1.]]。

[24] [[秒]]とその直前の [CODE[[[:]]]] は、省略できます [SRC[>>13 5.1, >>77 3.3., >>106 3.3., >>117 5.1.]]。

[27] [[RFC 822]] では範囲は 00 から 59 までとされています [SRC[>>13 5.1.]]。
従って[[正閏秒]]は表現できません。

[92] [[RFC 2822]]/[[RFC 5322]] と [[son-of-RFC 1036]] では範囲は 00 から 60 までとされており、
[[閏秒]]も反映されることになっています
[SRC[>>77 3.3., >>106 3.3., >>117 5.1.]]。

[87] [[小数部]]は認められていません。

* 時間帯

[28] [[RFC 822]] では[[時間帯]]は名前または[[時差]]によって表すことになっていました [SRC[>>13 5.1.]]。

[32] [[大文字]]と[[小文字]]は区別しません [SRC[>>13 3.4.7.]]。

;; [34] [[北米]]の3文字表記と[[時差]]の表記は [[ANSI X3.51-1975]] に由来するとされています
[SRC[>>13 5.2.]]。

[128] [[son-of-RFC 1036]] は[[時差]]と [CODE[[[GMT]]]] と [CODE[[[UT]]]]
のいずれかを使うことを要求しています [SRC[>>117 5.1.]]。

[38] [[RFC 822]] の一部を改訂する [[RFC 1123]] (や後の[[RFC2822の日付形式]]) は、
名前でなく[[時差]]によって表記する[['''べき''']]としています [SRC[>>44 5.2.14]]。

[62] [[電子メール]]関連仕様である [[RFC 2183]]、[[RFC 1894]]、[[RFC 2852]]、[[RFC 3464]] は、
それぞれの文脈においては[[時差]]によって表記しなければ[['''ならない''']] [SRC[>>61 2., >>72, >>71, >>70]]
としています。

[57] [[RFC 822]] の附属書Dは本文中の [[BNF]] [[生成規則]]をまとめたものですが、
[[時間帯]]の定義の[[時差]]の部分と[[注釈]]の一部が誤って欠落しています [SRC[>>44 5.2.14]]。

[115] [[RFC 1036]] は [CODE[[[GMT]]]]、北米の[[時間帯]]名、[[時差]]に対応するべき
[SRC[>>109]] としています。

;; [116] 他の[[時間帯]]名には対応しなくていいのか、生成しないだけで対応しなければいけないのかは不明瞭です。

[88] [[RFC 2822]]/[[RFC 5322]] では[[時間帯]]は[[時差]]によって表すことになっています [SRC[>>77 3.3., >>106 3.3.]]。

** 時差

[30] [[時差]]は、 [CODE[[[+]]]] または [CODE[[[-]]]] の[[符号]]の後、
2桁の[[数字]]による[[時]]と2桁の[[数字]]による[[分]]の2桁で表すことになっています [SRC[>>13 5.1.]]。

[43] [[時差]]の[[値域]]は [[RFC 822]] には明記されていませんでした。

[120] [[son-of-RFC 1036]] では[[時]]は23[[以下]]、[[分]]は59[[以下]]とされています [SRC[>>117 5.1.]]。

[93] [[RFC 2822]] では[[時]]は 99 [[以下]]、 [[分]]は 59 [[以下]]とされています
[SRC[>>77 3.3.]]。

[42] なお [CODE[[[+]]]] や [CODE[[[-]]]] は [CODE(ABNF)@en[[[atom]]]] に含まれる[[文字]]なので、
[[RFC 822]] における単独の[[字句]]となる区切り文字ではありません。従って、
これら[[符号]]と[[数字]]の間に [CODE(ABNF)@en[[[linear-white-space]]]] や
[CODE(ABNF)@en[[[comment]]]] を挿入することはできませんでした。

[90] [[RFC 2822]]/[[RFC 5322]] によれば、 [[UT]] を表すには [CODE[[[+0000]]]] を使う[['''べきです''']]
[SRC[>>77 3.3., >>106 3.3.]]。

[91] [[RFC 2822]]/[[RFC 5322]] によれば、 [CODE[[[-0000]]]] も [[UT]] を表しますが、
同時に他の[[地方時]]のシステムかもしれないシステムで生成されたことも表します
[SRC[>>77 3.3., >>106 3.3.]]。

** UTC の名前

[54] [CODE[[[UT]]]] と [CODE[[[GMT]]]] は、 [[UT]] を表します [SRC[>>13 5.1., >>94 4.3., >>106 4.3., >>117 5.1.]]。

[97] [[RFC 2822]]/[[RFC 5322]] ではこれらの使用は禁止されていますが、理解できなければ[['''なりません''']]
[SRC[>>94 4.3., >>106 4.3.]]。

[137] [[ネットニュース]]で用いられる [[RFC 5536]] は、 [CODE(822)[[[GMT]]]] も広く用いられているので[[適合]]とするが、生成しては[['''ならない''']]としています
[SRC[>>135]]。

;; [138] 適合するのに認められないとはどういう意味かわかりませんが...

** 北米時間帯の名前

[29] [[北米]]の主要な[[標準時]]と[[夏時刻]]を表す
[CODE[[[EST]]]], [CODE[[[EDT]]]], [CODE[[[CST]]]], [CODE[[[CDT]]]],
[CODE[[[MST]]]], [CODE[[[MDT]]]], [CODE[[[PST]]]], [CODE[[[PDT]]]]
が定義されており、それぞれ特定の (固定の) [[時差]]を表すこととされていました [SRC[>>13 5.1.]]。

[129] [[son-of-RFC 1036]] はこれらを禁止しており、解釈が混乱していると指摘しています
[SRC[>>117 5.1.]]。

[98] [[RFC 2822]]/[[RFC 5322]] ではこれらの使用は禁止されていますが、理解できなければ[['''なりません''']]
[SRC[>>94 4.3., >>106 4.3.]]。

** 米軍時間帯の名前

[55] [[RFC 822]] は[[米軍時間帯]]を表す1文字の[[ラテン文字]]の利用を認めていました
(ただし [CODE[[[J]]]] は未使用とされていました) [SRC[>>13 5.1.]]。

[39] [[RFC 733]] ([[RFC 822]] の前の世代), [[RFC 822]] の
[[BNF]] の[[注釈]]では[[符号]]が逆になっています。このため実装により解釈が正反対になってしまい、 
[[RFC 1123]] は「この書き方は情報を伝達しない」 [SRC[>>44 5.2.14]] としています。

[130] [[son-of-RFC 1036]] はこれらを禁止しています [SRC[>>117 5.1.]]。

[99] [[RFC 2822]]/[[RFC 5322]] は、これらの使用を禁止していますが、これら ([CODE[[[J]]]] 以外)
が使用された[[日時]]を理解できなければ[['''ならない''']]としています。ただし、外部情報が無い限り、
[CODE[[[-0000]]]] と解釈する[['''べき''']]だとしています。 [SRC[>>94 4.3., >>106 4.3.]]

;; [100] [CODE[[[Z]]]] も含まれています。

** その他の名前

[56] [[時間帯を表す文字列]]は前の世代の[[RFC733の日付形式]]から種類が減っています。
一方実際にはここで示されていないもの (例 JST = +0900) がしばしば
使われました。 (最近は少なくなりました。)

[101] [[RFC 2822]]/[[RFC 5322]] は、他の複数文字の名前について、歴史的に使われてきたことを認めた上で、
外部情報がなければ未知のものは [CODE[[[-0000]]]] と解釈する[['''べき''']]としています
[SRC[>>94 4.3., >>106 4.3.]]。

[102] 実際に使われてきた文字列は、[[時間帯を表す文字列]]を参照してください。
欧州やアジアや豪州の各地の[[時間帯]]が歴史的に用いられていました。中には意味が衝突しているものもあります。

** 時間帯の説明の注釈

[121] [[son-of-RFC 1036]] は、[[時差]]の直後に[[空白]]と[[注釈]]を置くことを認めていました
[SRC[>>117 5.1.]]。この[[注釈]]には、 [CODE[[[U+0020]]]]-[CODE[[[U+007E]]]]
を1文字以上含めなければなりません (ただし [CODE[[[(]]]], [CODE[[[)]]]], [CODE[[[\]]]] を除きます)
[SRC[>>117 5.1.]]。

;; [122] [[RFC 822]] では字句間の [CODE(ABNF)@en[[[comment]]]]、 [[RFC 2822]]/[[RFC 5322]]
では [[CFWS]] としてこの位置に[[注釈]]を含めることができますが、 [[son-of-RFC 1036]]
はそれに[[時間帯]]名という意味を与えています。

[123] これは[[注釈]]なので、表示しても構いませんが、解釈上は無視しなければ[['''なりません''']]
[SRC[>>117 5.1.]]。

** 時間帯の選択

[125] [[RFC 1036]] は、 [[GMT]] を用いて、表示の際に[[地方時]]に変換することを推奨していました
[SRC[>>109]]。

[126] [[son-of-RFC 1036]] は投稿者の[[時間帯]]を[[時差]]として記述し、
説明を[[注釈]]に含める[['''べき''']]としていました [SRC[>>117 5.1.]]。

;; [127] 投稿者の[[時間帯]]の方が有用な情報であるから変更した [SRC[>>117 5.1.]] と説明されています。

[124] [[RFC 2822]]/[[RFC 5322]] では、[[日時]]は[[地方時]]を表すものである[['''べき''']]とされています
[SRC[>>77 3.3., >>106 3.3.]]。

* ネットニュースにおける日時

[110] [[USENET]] 系[[ネットニュース]]は、[[電子メール]]ではありませんが、 [[RFC 822]] 
の[[メッセージ]]形式を採用しています。ただし、 [[RFC 822]] より構文が限定的になっている他、
[[USENET]] 独自の歴史的経緯により、実装上[[電子メール]]とは異なる配慮が必要なこともあります。

[111] [[ネットニュース]]については [[RFC 1036]] が長らく標準仕様と考えられてきました。
[[RFC 1036]] は、 [[RFC 822]] の定義に従い [[USENET]] のソフトウェアの [[getdate(3)]]
が認識できる書式を用いることを要求しています [SRC[>>109]]。具体的には記述されていませんが、
[PRE(code)[
Wdy, DD Mon YY HH:MM:SS TIMEZONE
]PRE]
... がそのような書式の1つである [SRC[>>109]] とされています。

[112] 一般に[[ネットニュース]]では [[CFWS]] の自由の挿入は認められていないと考えられていました。

[113] 更に [[RFC 1036]] は [[ctime(3)]] 形式の
[PRE(code)[
Wdy Mon DD HH:MM:SS YYYY
]PRE]
... は [[RFC 822]] に適合しないため認められないものの、用いられているため、対応するのが[RUBYB[良い]@en[encouraged]]
[SRC[>>109]] としていました。

;; [114] [[RFC 1036]] では [CODE(822)@en[[[Date:]]]], [CODE(822)@en[[[Expires:]]]] で使われていました。

[131] [[RFC 1036]] に変わって事実上の標準とみなされるようになった [[son-of-RFC 1036]]
は、より明確な定義を含んでおり (本項の他の部分で説明しています)、 >>113 のような推奨も含まれなくなっています。

;; [132] [[son-of-RFC 1036]] の時期にはもう古い形式は見られなくなっていたのでしょうか。

[136] [[RFC 1036]] と [[son-of-RFC 1036]] にかわって ([[ネットニュース]]が絶滅に近い状態になった)
2009年に出版された [[RFC 5536]] は、 [CODE[[[GMT]]]] の扱いを除き、 [[RFC 5322]]
を完全に参照しています [SRC[>>135]]。

* RSS 2.0 における日時

[4]
[[RSS 2.0]] は (仕様書内で一貫していない部分もありますが) [[RFC 822]] の[[日付形式]]を採用し、
[[年号]]は4桁でもよく、4桁が望ましいとしています [SRC[>>139]]。

[140] [[RSS 2.0]] [[文書]]に関して、 [[RSS Best Practices Profile]] は次のようなことを述べています
[SRC[>>5]]。
- [[4桁年号]]を使用[['''するべきです''']]。
- [[空白]]を使えるところに[[注釈]]を使ったり、複数個の[[間隔]]を挿入したり[['''するべきではありません''']]。
- [CODE(822)[[[Z]]]] 以外の1文字[[時間帯]]文字列は使用[['''するべきではありません''']]。
- [[UTC]] を使うのが最も[[相互運用性]]上優れているようです。
- [[月]]の名前は先頭を[[大文字]]、後は[[小文字]]に、[[時間帯]]の名前はすべて[[大文字]]に[['''するべきです''']]。
- [[日]]の[[先導零]]は省略[['''して構いません''']]。
- [[アメリカ合衆国]]の[[時間帯]]を表す文字列や丁度の[[時間]] (hour) の差を表す[[時間帯]]は[[相互運用性]]が高いようです。
- 調査対象すべてが対応していた[[時間帯]]は [CODE[[[GMT]]]]、[CODE[[[+0000]]]]、[CODE[[[-0000]]]] のみです。

[6]
現実の [[RSS]] [[文書]]の日付は [[RFC 822]] に適合していないことがあります。
例えば、[[時]]が1桁だったりします。

[3]
[[OPML]] は [[RFC 822の日付形式]]を採用しているとしています。
しかし、実例では[[4桁年号]]が用いられています。
実装が[[2桁年号]]や [CODE(ABNF)@en[[[comment]]]] に対応しているのかは謎です。

[FIG[
[FIGCAPTION[
[10] [CITE@ja[M.C.P.C.: 「RSS 簡単一発作成 『RSS 生成 CGI』」から書き出されるRSS 2.0の日付情報が不正なので直すパッチ]] ([TIME[2009-03-15 11:02:14 +09:00]] 版) <http://blog.dtpwiki.jp/dtp/2009/03/rss-rss-cgirss-.html>
]FIGCAPTION]

>>
-○正 > "Fri, 01 Jun 2005 03:00:00 +0900" (一例です 文字の間のスペースに注意してください)
-○誤 > "Fri, 01 Mar 2009 03:00:00 +09:00"
>とか出まして、RFC 822に従っていないので、XML::Feed(が使っているDateTime)が日付として認識できなかったようです。

>
RSS生成スクリプトでした。
>
RSS簡単一発作成『RSS 生成 CGI』 - futomi's CGI Cafe
<http://www.futomi.com/library/rss/index.html?1.1.0> [www.futomi.com]
]FIG]

* 文脈

[35] [[RFC 2183の日時形式]]は次の場面で使われています。
[FIG(list)[
- [CODE(MIME)@en[[[Content-Disposition:]]]] [[ヘッダー]] [CODE(MIME)@en[[[creation-date]]]] [[引数]]
- [CODE(MIME)@en[[[Content-Disposition:]]]] [[ヘッダー]] [CODE(MIME)@en[[[modification-date]]]] [[引数]]
- [CODE(MIME)@en[[[Content-Disposition:]]]] [[ヘッダー]] [CODE(MIME)@en[[[read-date]]]] [[引数]]
]FIG]

* 歴史

** RFC 822

[REFS[
- [59] [CITE@en[RFC 822 - STANDARD FOR THE FORMAT OF ARPA INTERNET TEXT MESSAGES]] ([TIME[2014-03-08 23:19:55 +09:00]] 版) <http://tools.ietf.org/html/rfc822#section-5>
]REFS]

[FIG[
* 5.  DATE AND TIME SPECIFICATION

** 5.1.  SYNTAX

[PRE[
     date-time   =  [ day "," ] date time        ; dd mm yy
                                                 ;  hh:mm:ss zzz
]PRE]

[PRE[
     day         =  "Mon"  / "Tue" /  "Wed"  / "Thu"
                 /  "Fri"  / "Sat" /  "Sun"
]PRE]

[PRE[
     date        =  1*2DIGIT month 2DIGIT        ; day month year
                                                 ;  e.g. 20 Jun 82
]PRE]

[PRE[
     month       =  "Jan"  /  "Feb" /  "Mar"  /  "Apr"
                 /  "May"  /  "Jun" /  "Jul"  /  "Aug"
                 /  "Sep"  /  "Oct" /  "Nov"  /  "Dec"
]PRE]

[PRE[
     time        =  hour zone                    ; ANSI and Military
]PRE]

[PRE[
     hour        =  2DIGIT ":" 2DIGIT [":" 2DIGIT]
                                                 ; 00:00:00 - 23:59:59
]PRE]

[PRE[
     zone        =  "UT"  / "GMT"                ; Universal Time
                                                 ; North American : UT
                 /  "EST" / "EDT"                ;  Eastern:  - 5/ - 4
                 /  "CST" / "CDT"                ;  Central:  - 6/ - 5
                 /  "MST" / "MDT"                ;  Mountain: - 7/ - 6
                 /  "PST" / "PDT"                ;  Pacific:  - 8/ - 7
                 /  1ALPHA                       ; Military: Z = UT;
                                                 ;  A:-1; (J not used)
                                                 ;  M:-12; N:+1; Y:+12
                 / ( ("+" / "-") 4DIGIT )        ; Local differential
                                                 ;  hours+min. (HHMM)
]PRE]

** 5.2.  SEMANTICS

[PRE[
          If included, day-of-week must be the day implied by the date
     specification.
]PRE]

[PRE[
          Time zone may be indicated in several ways.  "UT" is Univer-
     sal  Time  (formerly called "Greenwich Mean Time"); "GMT" is per-
     mitted as a reference to Universal Time.  The  military  standard
     uses  a  single  character for each zone.  "Z" is Universal Time.
     "A" indicates one hour earlier, and "M" indicates 12  hours  ear-
     lier;  "N"  is  one  hour  later, and "Y" is 12 hours later.  The
     letter "J" is not used.  The other remaining two forms are  taken
     from ANSI standard X3.51-1975.  One allows explicit indication of
     the amount of offset from UT; the other uses  common  3-character
     strings for indicating time zones in North America.
]PRE]
]FIG]

** RFC 1036

[FIG[
* 2.1.2.  Date

    The "Date" line (formerly "Posted") is the date that the message was
    originally posted to the network.  Its format must be acceptable
    both in RFC-822 and to the getdate(3) routine that is provided with
    the Usenet software.  This date remains unchanged as the message is
    propagated throughout the network.  One format that is acceptable to
    both is:

                      Wdy, DD Mon YY HH:MM:SS TIMEZONE

    Several examples of valid dates appear in the sample message above.
    Note in particular that ctime(3) format:

                          Wdy Mon DD HH:MM:SS YYYY

    is not acceptable because it is not a valid RFC-822 date.  However,
    since older software still generates this format, news
    implementations are encouraged to accept this format and translate
    it into an acceptable format.

    There is no hope of having a complete list of timezones.  Universal
    Time (GMT), the North American timezones (PST, PDT, MST, MDT, CST,
    CDT, EST, EDT) and the +/-hhmm offset specifed in RFC-822 should be
    supported.  It is recommended that times in message headers be
    transmitted in GMT and displayed in the local time zone.
]FIG]

** RFC 1123

[45] [[RFC 1123]] は、 [[RFC 822]] の[[日時]]の部分の一部を改訂しています。

[REFS[
- [60] [CITE@en[RFC 1123 - Requirements for Internet Hosts - Application and Support]] ([TIME[2014-03-19 20:00:09 +09:00]] 版) <http://tools.ietf.org/html/rfc1123#page-55>
]REFS]

[FIG[
* 5.2.14  RFC-822 Date and Time Specification: RFC-822 Section 5

[PRE[
         The syntax for the date is hereby changed to:
]PRE]

[PRE[
            date = 1*2DIGIT month 2*4DIGIT
]PRE]

[PRE[
         All mail software SHOULD use 4-digit years in dates, to ease
         the transition to the next century.
]PRE]

[PRE[
         There is a strong trend towards the use of numeric timezone
         indicators, and implementations SHOULD use numeric timezones
         instead of timezone names.  However, all implementations MUST
         accept either notation.  If timezone names are used, they MUST
         be exactly as defined in RFC-822.
]PRE]

[PRE[
         The military time zones are specified incorrectly in RFC-822:
         they count the wrong way from UT (the signs are reversed).  As
         a result, military time zones in RFC-822 headers carry no
         information.
]PRE]

[PRE[
         Finally, note that there is a typo in the definition of "zone"
         in the syntax summary of appendix D; the correct definition
         occurs in Section 3 of RFC-822.
]PRE]
]FIG]

** RFC 2822

[FIG[
*RFC 2822 3.3. Date and Time Specification

>   Date and time occur in several header fields.  This section specifies
the syntax for a full date and time specification.  Though folding
white space is permitted throughout the date-time specification, it
is RECOMMENDED that a single space be used in each place that FWS
appears (whether it is required or optional); some older
implementations may not interpret other occurrences of folding white
space correctly.

>日付と時刻は幾つかの頭欄に現れます。この節では完全な日付と時刻の記述の構文を規定します。折畳み空白間隔は
date-time 記述の至る所で認められていますが、 FWS
が出現する各部位では (必須であろうと省略可能であろうと)
1つの間隔を使用することを'''推奨します'''。
古い実装は折畳み空白間隔を正しく解釈しないかもしれません。

-date-time       =       [ day-of-week "," ] date FWS time [CFWS]
-day-of-week     =       ([FWS] day-name) / obs-day-of-week
-day-name        =       "Mon" / "Tue" / "Wed" / "Thu" / "Fri" / "Sat" / "Sun"
-date            =       day month year
-year            =       4*DIGIT / obs-year
-month           =       (FWS month-name FWS) / obs-month
-month-name      =       "Jan" / "Feb" / "Mar" / "Apr" /                        "May" / "Jun" / "Jul" / "Aug" /                        "Sep" / "Oct" / "Nov" / "Dec"
-day             =       ([FWS] 1*2DIGIT) / obs-day
-time            =       time-of-day FWS zone
-time-of-day     =       hour ":" minute [ ":" second ]
-hour            =       2DIGIT / obs-hour
-minute          =       2DIGIT / obs-minute
-second          =       2DIGIT / obs-second
-zone            =       (( "+" / "-" ) 4DIGIT) / obs-zone

>   The day is the numeric day of the month.  The year is any numeric
year 1900 or later.

> day (日) は月の中の日を数値で表したものです。 year (年)
は1900年以降の数値で表した年です。

>   The time-of-day specifies the number of hours, minutes, and
optionally seconds since midnight of the date indicated.

time-of-day (日の時刻) は時と分、それに省略可能ですが秒を指定します。これは示す日付の真夜中から起算したものです。

>   The date and time-of-day SHOULD express local time.

date (日付) と time-of-day (日の時刻) は地方時を表現するのが
'''良いです'''。

>   The zone specifies the offset from Coordinated Universal Time (UTC,
formerly referred to as "Greenwich Mean Time") that the date and
time-of-day represent.  The "+" or "-" indicates whether the
time-of-day is ahead of (i.e., east of) or behind (i.e., west of)
Universal Time.  The first two digits indicate the number of hours
difference from Universal Time, and the last two digits indicate the
number of minutes difference from Universal Time.  (Hence, +hhmm
means +(hh * 60 + mm) minutes, and -hhmm means -(hh * 60 + mm)
minutes).  The form "+0000" SHOULD be used to indicate a time zone at
Universal Time.  Though "-0000" also indicates Universal Time, it is
used to indicate that the time was generated on a system that may be
in a local time zone other than Universal Time and therefore
indicates that the date-time contains no information about the local
time zone.

zone (帯) は date と time-of-date の協定世界時 (UTC;
以前はグリニッジ標準時として知られていました。[INS[訳注: 厳密には UTC と GMT は異なりますが、計算機分野ではあまり区別されません。]]) 
からの時差を指定します。 "+" と "-" は time-of-date
が世界時の先 (つまり東) か後 (つまり西) かを示します。
最初の2桁は世界時との時の差の値を、後の2桁は世界時との分の差の値を示します。
(よって、 +hhmm は +(hh * 60 + mm) 分を表します。)
"+0000" は世界時の時間帯を表すのに使用'''するのがよいです'''。
"-0000" も世界時を表しますが、世界時以外の地方時かもしれない処理系で時刻が生成されたことを示すのに使われるので、
date-time が地方時間帯についての情報を含んでいないことを示します。

>A date-time specification MUST be semantically valid.  That is, the
day-of-the-week (if included) MUST be the day implied by the date,
the numeric day-of-month MUST be between 1 and the number of days
allowed for the specified month (in the specified year), the
time-of-day MUST be in the range 00:00:00 through 23:59:60 (the
number of seconds allowing for a leap second; see [STD12]), and the
zone MUST be within the range -9959 through +9959.

date-time 記述は意味的に妥当なもので'''なければなりません'''。
これは、曜日は (含まれていれば) 日付の暗示する曜日で'''なければならず'''、
day-of-month の数値は1から (指定した年の) 
指定した月であり得る日の数までの間で'''なければなりません'''し、
time-of-day は範囲 00:00:00 〜 23:59:60 (閏秒で認められる秒の数。
STD12 参照。) の間に'''なければなりません'''し、
zone は範囲 -9959 〜 +9959 の中に'''なければなりません'''。

*RFC 2822 4.3. Obsolete Date and Time

>The syntax for the obsolete date format allows a 2 digit year in the
date field and allows for a list of alphabetic time zone
specifications that were used in earlier versions of this standard.
It also permits comments and folding white space between many of the
tokens.

時代遅れの日付形式は日付欄中で2桁年号を認めており、またこの規格の早期の版で使われていたアルファベットの時間帯記述の表も認めています。また、多くの字句の間に注釈や折畳み空白間隔を許しています。

-obs-day-of-week =       [CFWS] day-name [CFWS]
-obs-year        =       [CFWS] 2*DIGIT [CFWS]
-obs-month       =       CFWS month-name CFWS
-obs-day         =       [CFWS] 1*2DIGIT [CFWS]
-obs-hour        =       [CFWS] 2DIGIT [CFWS]
-obs-minute      =       [CFWS] 2DIGIT [CFWS]
-obs-second      =       [CFWS] 2DIGIT [CFWS]

[PRE[
obs-zone        =       "UT" / "GMT" /          ; Universal Time
                                                ; North American UT
                                                ; offsets

                        "EST" / "EDT" /         ; Eastern:  - 5/ - 4
                        "CST" / "CDT" /         ; Central:  - 6/ - 5
                        "MST" / "MDT" /         ; Mountain: - 7/ - 6
                        "PST" / "PDT" /         ; Pacific:  - 8/ - 7

                        %d65-73 /               ; Military zones - "A"
                        %d75-90 /               ; through "I" and "K"
                        %d97-105 /              ; through "Z", both
                        %d107-122               ; upper and lower case
]PRE]

>Where a two or three digit year occurs in a date, the year is to be
interpreted as follows: If a two digit year is encountered whose
value is between 00 and 49, the year is interpreted by adding 2000,
ending up with a value between 2000 and 2049.  If a two digit year is
encountered with a value between 50 and 99, or any three digit year
is encountered, the year is interpreted by adding 1900.

日付中に2桁か3桁の数値が出てきたら、年は次のように解釈します。
2桁の数字が値 00 〜 49 の間で出てきた場合、年は
2000 を足して 2000 〜 2049 として解釈します。2桁の数字が値
50 〜 99 で出てきた場合、または3桁の数字の年が現れた場合は、年は
1900 を加えて解釈します。

>In the obsolete time zone, "UT" and "GMT" are indications of
"Universal Time" and "Greenwich Mean Time" respectively and are both
semantically identical to "+0000".

時代遅れの時間帯 "UT" と "GMT" は「世界時」と「グリニッジ標準時」
をそれぞれ表し、共に意味的には "+0000" と同等です。

>The remaining three character zones are the US time zones.  The first
letter, "E", "C", "M", or "P" stands for "Eastern", "Central",
"Mountain" and "Pacific".  The second letter is either "S" for
"Standard" time, or "D" for "Daylight" (or summer) time.  Their
interpretations are as follows:

残りの3文字の帯は合衆国の時間帯です。最初の文字 "E", "C",
"M", "P" は「東部」, 「中部」, 「山岳部」, 「太平洋」
を意味します。2文字目は「標準」時の "S" か、「夏」時間の "D"
です。これらの解釈は次のようにします。

   EDT is semantically equivalent to -0400
   EST is semantically equivalent to -0500
   CDT is semantically equivalent to -0500
   CST is semantically equivalent to -0600
   MDT is semantically equivalent to -0600
   MST is semantically equivalent to -0700
   PDT is semantically equivalent to -0700
   PST is semantically equivalent to -0800

The 1 character military time zones were defined in a non-standard
way in [RFC822] and are therefore unpredictable in their meaning.
The original definitions of the military zones "A" through "I" are
equivalent to "+0100" through "+0900" respectively; "K", "L", and "M"
are equivalent to  "+1000", "+1100", and "+1200" respectively; "N"
through "Y" are equivalent to "-0100" through "-1200" respectively;
and "Z" is equivalent to "+0000".  However, because of the error in
[RFC822], they SHOULD all be considered equivalent to "-0000" unless
there is out-of-band information confirming their meaning.

1文字の軍の時間帯は RFC 822 で標準でない方法で定義されており、従ってその意味は予想出来ません。軍の帯の元の定義は
"A" から "I" は "+0100" から "+0900" とそれぞれ等しく、
"K", "L", "M" は "+1000", "+1100", "+1200" とそれぞれ等しく、
"N" から "Y" はそれぞれ "-0100" から "-1200" とそれぞれ等しく、
"Z" は "+0000" と等しいというものでした。しかし RFC 822
の誤りのため、その意味を確認する外部情報がない限りこれらはすべて
"-0000" と等しいとみなす'''のが良いです'''。

[INS[
RFC 822 では、本文と BNF で説明が違っていました。
これは RFC 733 から引き継いだ間違いでした。
]INS]

>Other multi-character (usually between 3 and 5) alphabetic time zones
have been used in Internet messages.  Any such time zone whose
meaning is not known SHOULD be considered equivalent to "-0000"
unless there is out-of-band information confirming their meaning.

他の複数文字 (通常3〜5文字の間) のアルファベットの時間帯が
Internet メッセージで使われてきました。こうした時間帯で意味を知らないものは、その意味を確認する外部情報がない限り
"-0000" と等しいとみなす'''のが良いです'''。
]FIG]

* 関連

[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の日付形式]]を採用しています。

[REFS[
- [11] [CITE[OASIS CAM V1.1 Specification]]
( ([TIME[2007-06-18 21:16:59 +09:00]] 版))
<http://docs.oasis-open.org/cam/v1.1/os/OASIS-CAM-Specification-1_1-015-060107.html>
]REFS]

[107] >>11 は[[RFC 822]]の[[時間帯]]と称して、「±HHMM」表記の[[時差]]に対応しています。

* 例

-[67] [CODE(MIME example)[Fri, 27 Dec 2002 09:25:00 +0900]]
-[7]  [CODE(example)[Thu, 04 Oct 2007 23:59:45 +0000]] [SRC@en[[[RSS Best Practices Profile]] >>5]]
-[8]  [CODE(example)[Thu, 04 Oct 2007 23:59:45 -0000]] [SRC@en[[[RSS Best Practices Profile]] >>5]]
-[9]  [CODE(example)[Thu, 04 Oct 2007 23:59:45 GMT]] [SRC@en[[[RSS Best Practices Profile]] >>5]]

* メモ

[1] 1993年の調査では半分くらいのメッセージが4桁年号に移行していたとか。 (RFC 1123 は1989年。) 時間帯は数値指定も多いものの文字列指定のほうが圧倒的ですかね。非標準名もよく見かけます。

[2] [WEAK[2003-01-25 14:07]] ''>>1'': 今でも文字列名の時間帯はたまに見かけますね。2桁年号とか、秒指定がないのとかはもう何年も見ていませんが。