[12] 本項では、[[インターネット]]の[[電子メール]]および派生仕様において用いられている[[日時形式]]を説明します。 [[電子メール]] ([[RFC 822]]) の[[日時形式]]は、後に [[RFC 3339]] が出版されるまで、 [[インターネット]]の標準的な[[日時]]の表現形式とみなされてきました。そのため[[電子メール]]以外でも多くの[[プロトコル]]でこの形式が採用されました。 [145] この[[日時形式]]は元々[[人間]]の読み書きと機械的な読み書きの両方が想定された折衷的な形式で、なおかつ自由度も高かったため、非標準なものも含め様々なバリエーションがありました。時代が下るにつれ[[相互運用性]]や実装の簡便性への関心の高まりから、各プロトコルでそれぞれの事情に合わせた制約が追加されていきました。 ;; [150] 派生した [[HTTP]] での[[日時形式]]については、[[HTTPの日時形式]]を参照。 * 代替 [160] この[[日時形式]]は、歴史的な経緯から必要以上に複雑である一方で[[仕様書]]には曖昧な点も残るため、新しい技術は採用するべきではありません。 [161] [[HTMLの日時形式]]など他の明確に規定されている形式を使うべきです。 * 仕様書 [REFS[ - [13] [CITE@en[RFC 822 - STANDARD FOR THE FORMAT OF ARPA INTERNET TEXT MESSAGES]] ([TIME[2014-03-08 23:19:55 +09:00]] 版) - [44] [CITE@en[RFC 1123 - Requirements for Internet Hosts - Application and Support]] ([TIME[2014-03-19 20:00:09 +09:00]] 版) - [106] [CITE@en[RFC 5322 - Internet Message Format]] ([TIME[2014-05-13 12:04:08 +09:00]] 版) -- [77] 旧版 [CITE@en[RFC 2822 - Internet Message Format]] ([TIME[2014-03-08 23:10:45 +09:00]] 版) -- [94] 旧版 [CITE@en[RFC 2822 - Internet Message Format]] ([TIME[2014-03-08 23:10:45 +09:00]] 版) - [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]] 版) - [70] [CITE@en[RFC 3464 - An Extensible Message Format for Delivery Status Notifications]] ([TIME[2014-02-09 11:19:25 +09:00]] 版) -- [72] 旧版 [CITE@en[RFC 1894 - An Extensible Message Format for Delivery Status Notifications]] ([TIME[2014-03-09 10:00:41 +09:00]] 版) - [71] [CITE@en[RFC 2852 - Deliver By SMTP Service Extension]] ([TIME[2014-04-20 15:19:04 +09:00]] 版) - [48] [CITE@en[RFC 3801 - Voice Profile for Internet Mail - version 2 (VPIMv2)]] ([TIME[2014-09-07 15:46:36 +09:00]] 版) ]REFS] [68] [[電子メールの日時形式]]の歴史は長いですが、現在では実用上[TIME[西暦1982(昭和57)年][1982]]の [[RFC 822]] (>>13) 以降を考慮すれば十分です。これ以降の歴代仕様の中では [[RFC 822]] が最も緩い (自由度の高い) 構文を定義しており、時代が進むにつれ、より限定的な構文へと変化してきています。 [63] [[RFC 822]] (>>13) は、長らく[[インターネット]]の[[電子メール]]の標準仕様となっていました。 [[RFC 822]] の[[メッセージ]]形式は、[[電子メール]]のみならず、[[USENET]] 系[[ネットニュース]]に使われたり、派生形が [[HTTP]] その他の[[プロトコル]]で採用されたり、 [[インターネット]]の多くの[[プロトコル]]に影響を与えました。 [[RFC 822]] の定義する[[日時形式]]も、 [[HTTPの日付形式]]の一つとして採用されたり、 [[RSS]] など[[電子メール]]と直接関係しない[[プロトコル]]に採用されるなどして広く用いられました。 ;; [74] [[HTTP]] における[[日時形式]]については、本項ではなく、[[HTTPの日付形式]]を参照してください。 [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] [TIME[西暦2001(平成13)年][2001]]の [[RFC 2822]] (>>77) は [[RFC 822]] の全面改訂です。[[日時形式]]に関しても、 [[RFC 822]] + [[RFC 1123]] の構文に対して大きな制約を加えています。 [[RFC]] としては 2822 は 822 を廃止して置き換えるものですが、 [[IETF]] の手続き上の理由により、[[インターネット標準]]としては [[RFC 822]] が引き続き (形式的に) 存続しています。 [[RFC 822]] の圧倒的な知名度から、 2822 の出版以後も [[RFC]] 以外からは [[RFC 822]] が参照され続けています。 [116] [[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]] 版) - [117] [CITE@en[RFC 1849]] ([TIME[2014-03-09 17:56:58 +09:00]] 版) - [144] [CITE@en[RFC 5536 - Netnews Article Format]] ([TIME[2014-09-21 18:14:06 +09:00]] 版) - [135] [CITE@en[RFC 5536 - Netnews Article Format]] ([TIME[2014-03-09 09:57:58 +09:00]] 版) ]REFS] -*-*- [120] [[インターネットメール]]と関連仕様以外で [[RFC 822の日時形式]]を採用した代表例として、 [[RSS 2.0]] があります。 [REFS[ - [139] [CITE[RSS 2.0 Specification]] ([TIME[2007-01-03 19:03:10 +09:00]] 版) - [5] [CITE@en[RSS Best Practices Profile]] ([TIME[2008-10-23 18:58:35 +09:00]] 版) ]REFS] * 構文 [14] 「曜日(英略), 日月(英略) 年時:分:秒時間帯」という形式です。このうち、曜日と秒は省略可能です。 [FIG(railroad)[ = ? == 曜日 == [CODE[[[,]]]] = 日 = 月 = 年 = 時 = [CODE[[[:]]]] = 分 = ? == [CODE[[[:]]]] == 秒 = 時間帯 ]FIG] [58] [[RFC 822]] の message 例中に登場する日付「27 Aug 76 0932 PDT」は時・分の間に「:」が入らない [[RFC 733以前の書き方][RFC 733の日付形式]]で、不適当な例文です。 [121] 著者の意図が旧方式の廃止だったのか存続だったのかはよくわかりませんが、実際のほぼすべての [[MUA]] は [CODE[:]] 付きで出力します。 [CODE[:]] 無しの入力に対応しているかどうかは定かではありませんが、対応していないものも多そうです。 * 空白と注釈 [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] 後述の通り、[[時間帯]]の名前としての[[注釈]]のみ認めていました。 [122] 実際には [[RFC 822]] が認めるような構文上の自由度を活用した記述はほとんど行われておらず、 [[RFC 2822]] が[[生成]]に於いて要求するような構文が固定的に用いられることがほとんどです。 [123] それでも受信に於いてはすべてのあり得る入力に対応しなければなりませんが、実際にはそこまで完全でない実装もあります。 [124] [[注釈]]が使われることはほぼありませんが、唯一の例外として、末尾に[[時間帯名]] (英字3字の略称など) を書き入れることがしばしばあります。 [[RFC 822]] 時代には ([[北米]]を中心に) [[時間帯名]]を指定できましたが、 [[RFC 2822]] 時代には数値指定の[[生成]]しか認められないことになりました。実際にはその少し前から数値指定が主流になりつつありました。その際に[[注釈]]という形で従来の記述方法を残置したものと思われます。 * 暦法 [156] [[暦法]]は必ずしも明確ではありませんが、[[グレゴリオ暦]]の[[日時]]であると解釈されています。 [157] [[米国]]で作られ使われ始めた[[日時形式]]であることから自然に選択されたものです。 [158] [[グレゴリオ改暦]]以前の[[日付]]の解釈は不明です。 [[RFC 822]] では[[2桁年号]]しか認められていなかったので、この問題はありませんでした。 [[RFC 1123]] 以後[[年]]が4桁で記述されるようになったために、 [[過去の日時]]の解釈の問題が生じています。しかし [[RFC 1123]] などは[[インターネットメール]]のための仕様であり、 [[グレゴリオ改暦]]以前の[[日付]]を扱う必要がなかったため、敢えて定めようという考えに至らなかったのでしょう。 ;; [159] [[インターネットメール]]では問題にならないとしても、この[[日時形式]]を他の[[応用]]で採用するとそれが問題となる場合があるので、要注意です。 * 曜日 [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(short list)[ - [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年までの解釈が異なります。 [141] [[VPIMv2]] を規定する [[RFC 3801]] は2004年に出版されたにも関わらず、 2桁年号の例を示しています [SRC[>>48]]。 ;; 旧版が20世紀に出版されたものをまともにチェックせずに改訂再出版したからでしょうが... [98] [[西暦1万年問題]]には未対応です。 [125] [[年]]は、[[西暦年]]として解釈されます。それ以外の[[紀年法]]は使えません。 ;; [126] もちろんこれはあくまで[[プロトコル要素]]としての構文であり、 [[MUA]] は[[ロケール]]等に応じて適切な[[紀年法]]で表示することが期待されます。 ;; [127] 歴史的には [[MUA]] は[[プロトコル要素]]のそのままの構文で[[人間]]に入出力させる実装が多く、そのため[[米国人]]にとって読み書きしやすい構文が採用された経緯があり、自然と[[キリスト紀元]]が選ばれました。元は[[2桁西暦年号]]が使われたのも、それが当時の[[米国人]]の一般的な表記法だったためと思われます。 * 時 [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.]]。 [128] つまり[[閏秒のない時刻系]]が想定されていたと思われるところ、 [[閏秒]]ありの[[時刻系]]に改められた形になっています。しかしこれが実態を反映したものとは思われず、一般的な [[MUA]] はその[[プラットフォーム]]の[[時刻]]を使っていると思われますから、記述されたのは[[閏秒のない時刻系]]での[[時刻]]の可能性が高いです。 [129] 60秒の値が指定されたときに [[MUA]] が適切に取り扱いできるのかは怪しいと思われます。 [130] [[閏秒]]が存在しない60秒の値が指定されたときや、[[負閏秒]]であるにも関わらず59秒が指定されたとき、 [[MUA]] がどう処理するべきかは不明です。 [87] [[小数部]]は認められていません。 * 時間帯 [28] [[インターネットメールの時間帯表記]]を参照。 * ネットニュースにおける日時 [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, >>144]]。 * 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(quote)[ [FIGCAPTION[ [10] [CITE@ja[M.C.P.C.: 「RSS 簡単一発作成『RSS 生成 CGI』」から書き出されるRSS 2.0の日付情報が不正なので直すパッチ]] ([TIME[2009-03-15 11:02:14 +09:00]] 版) ]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 [www.futomi.com] ]FIG] ** SmartFormat [32] [[SmartFormat]] (「RSS2.0準拠」を称するが [[RSS 2.0]] とは互換性がない) の[[日時形式]]。 [30] [CITE@ja[SmartFormat仕様書(RSS2.0準拠) – SmartNews 媒体運営者サポートサイト]], [TIME[2020-10-07T03:52:40.000Z]] >フォーマットは RFC822 に定められたものする [[RSS 2.0]] ではなく [[RFC 822]] を参照。本文ではまた別の説明。 [38] [[SmartFormat]] (「Atom準拠」を称するが [[Atom 1.0]] とは互換性がない) の[[日時形式]]。 [[Atom]] 本来の形式の説明と [[RSS 2.0の日時形式]]系統の説明が混在。 (実装がどうなっているのか不明。) [34] [CITE@ja[SmartFormat仕様書(Atom準拠) – SmartNews 媒体運営者サポートサイト]], [TIME[2020-10-07T03:54:47.000Z]] [FIG(quote)[ [FIGCAPTION[ [39] [CITE@ja[SmartFormat仕様書(Atom準拠) – SmartNews 媒体運営者サポートサイト]], [TIME[2020-10-07T04:02:35.000Z]] ]FIGCAPTION] >記事の公開日(フォーマットは W3CDTF に定められたものとする) ]FIG] [42] [[Atom 1.0の日時形式]]は [[W3C-DTF]] とは異なる。この実装は仕様違反。 [115] こんな技術的レベルが低くても [[SmartNews]] という[[スマートフォンアプリ]]は普及しているのでこの形式もよく使われていると推測される。技術レベルの高い低いと市場で成功するかどうかは無関係だとよくわかる。不幸中の幸いなのは、この形式を処理するのは [[SmartNews]] 社内システムだけなので、外部の一般の技術者はこの形式をどう扱うか考えなくてすむこと。ただし社外の一般の技術者もこの形式で生成しなければならない場面はある。 * 文脈 [99] [[RFC 822の日時形式]]: - [[RFC 822メッセージ]] [102] [[RFC 1123の日時形式]] - [[CEA-2014-B]] [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] [143] [[RFC 5322の日時形式]]は [[RFC 5547]] が規定する [[SDP]] の[[属性]]でも使われています。 ;; [CODE(MIME)@en[[[Content-Disposition:]]]] の[[引数]]に相当するもので、そちらでは [[RFC 2183の日時形式]]が使われています (>>35)。 [FIG(list)[ - [CODE[[['file-date']]]] [[属性]] [CODE[[['creation']]]] [[引数]] - [CODE[[['file-date']]]] [[属性]] [CODE[[['modification']]]] [[引数]] - [CODE[[['file-date']]]] [[属性]] [CODE[[['read']]]] [[引数]] ]FIG] [146] [CITE@ja-JP[Twilio Doc - REST API]] ([TIME[2015-07-14 22:37:48 +09:00]] 版) [FIG(quote)[ [FIGCAPTION[ [147] [CITE@ja[ScalaでRSSフィードの処理を書いてみたら思ったより大変でした - argius note]] ([TIME[2016-01-07 17:36:18 +09:00]] 版) ]FIGCAPTION] > RSS2.0の日付もRFC 3339になっているケースが割とありました。 ]FIG] [FIG(quote)[ [FIGCAPTION[ [148] [CITE[RSS で pubDate や lastBuildDate を出力する時に気になる DATE_RFC822 や DATE_RFC2822 の違いについて | ウェブル]] ([[Weble]] 著, [TIME[2016-01-07 18:01:56 +09:00]] 版) ]FIGCAPTION] > 以前ブログにメモするときに DATE_RFC822 をすれば良いと書きましたが、しっかり見てみると間違ってます。というかコメントでアドバイス頂けてるのに気付いてませんでした。正確には DATE_RFC2822 で4桁で表示しなければいけないようです。 ]FIG] [149] [[IETF]] が[[差分仕様書]]というわかりにくい形で仕様を改訂し、日時処理ライブラリーの開発者がなぜか元の [[RFC 822]] 形式を実装し、ドキュメントに何を選ぶのが正しいか明確に記述しなかった、という不幸が重なり事情を知らない開発者が混乱し、結果ゴミデータが蔓延する、とかいう悲劇が21世紀になって10年経っても未だに続いているとかわらえない。 [FIG(quote)[ [FIGCAPTION[ [151] [CITE@en[RFC 5321 - Simple Mail Transfer Protocol]] ([TIME[2016-01-10 14:43:30 +09:00]] 版) ]FIGCAPTION] > SMTP > servers that create Received header fields SHOULD use explicit > offsets in the dates (e.g., -0800), rather than time zone names of > any type. Local time (with an offset) SHOULD be used rather than UT > when feasible. This formulation allows slightly more information > about local circumstances to be specified. If UT is needed, the > receiver need merely do some simple arithmetic to convert the values. > Use of UT loses information about the time zone-location of the > server. If it is desired to supply a time zone name, it SHOULD be > included in a comment. ]FIG] [155] [CITE@en[RFC 5260 - Sieve Email Filtering: Date and Index Extensions]] ([TIME[2017-05-07 22:48:17 +09:00]]) [FIG(quote)[ [FIGCAPTION[ [29] [CITE@en[Git - git-commit Documentation]] ([TIME[2018-03-04 14:30:28 +09:00]]) ]FIGCAPTION] > RFC 2822 > The standard email format as described by RFC 2822, for example Thu, 07 Apr 2005 22:13:13 +0200. ]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の日付形式]]を採用しています。 [101] [[mbox]] は [[ctime]] 形式を採用しています。 [REFS[ - [11] [CITE[OASIS CAM V1.1 Specification]] ( ([TIME[2007-06-18 21:16:59 +09:00]] 版)) ]REFS] [107] >>11 は[[RFC 822]]の[[時間帯]]と称して、「±HHMM」表記の[[時差]]に対応しています。 [100] [[IMAP]] では似て非なる形式が使われます。 [SEE[ [[IMAPの日時形式]] ]] * 例 -[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]] * 歴史 - [54] [[FTPメールの日時形式]] - [43] [[RFC 561の日時形式]] - [57] [[RFC 680の日時形式]] - [56] [[RFC 724の日時形式]] - [55] [[RFC 733の日時形式]] - [62] [[RFC 788の日時形式]] - [90] [[RFC 1153]] - [93] [[NNTPの日時形式]] - [91] [[Sieveの日時形式]] ** RFC 822 [88] [CITE@en[[[RFC 821]] - Simple Mail Transfer Protocol]], [TIME[2021-01-24T15:39:07.000Z]], [TIME[2021-03-10T06:20:45.361Z]] [REFS[ - [59] [CITE@en[[[RFC 822]] - STANDARD FOR THE FORMAT OF ARPA INTERNET TEXT MESSAGES]] ([TIME[2014-03-08 23:19:55 +09:00]] 版) ]REFS] [FIG(quote)[ [137] [[RFC 822]] * 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(quote)[ [138] [[RFC 1036]] * 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]] 版) ]REFS] [FIG(quote)[ [142] [[RFC 1123]] * 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(quote)[ [152] [[RFC 2822]] *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] [154] [[RFC 3339]] は [[RFC 2822の日時形式]]を [DFN@en[Email Date/Time Format]] と呼んでいます [SRC[>>153]]。 [REFS[ - [153] [CITE@en[RFC 3339 - Date and Time on the Internet: Timestamps]] ([TIME[2017-05-07 16:17:18 +09:00]]) ]REFS] [1] 1993年の調査では半分くらいのメッセージが4桁年号に移行していたとか。 (RFC 1123 は1989年。) 時間帯は数値指定も多いものの文字列指定のほうが圧倒的ですかね。非標準名もよく見かけます。 [2] [WEAK[2003-01-25 14:07]] ''>>1'': 今でも文字列名の時間帯はたまに見かけますね。2桁年号とか、秒指定がないのとかはもう何年も見ていませんが。 [97] [CITE[RFC Errata Report » RFC Editor]], [TIME[2021-04-21T09:18:32.000Z]] * メモ [FIG(amazon)[ 電子メールプロトコル ]FIG]