RFC 822の日時形式

インターネットメールの日時形式

[12] 本項では、インターネット電子メールおよび派生仕様において用いられている日時形式を説明します。 電子メール (RFC 822) の日時形式は、後に RFC 3339 が出版されるまで、 インターネットの標準的な日時の表現形式とみなされてきました。 そのため電子メール以外でも多くのプロトコルでこの形式が採用されました。

[145] この日時形式は元々人間の読み書きと機械的な読み書きの両方が想定された折衷的な形式で、 なおかつ自由度も高かったため、非標準なものも含め様々なバリエーションがありました。 時代が下るにつれ相互運用性や実装の簡便性への関心の高まりから、 各プロトコルでそれぞれの事情に合わせた制約が追加されていきました。

[150] 派生した HTTP での日時形式については、HTTPの日時形式を参照。

仕様書

[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 を廃止し、置き換える小改訂です。

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

構文

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

  1. ?
    1. 曜日
    2. ,
  2. :
  3. ?
    1. :
  4. 時間帯

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

空白と注釈

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

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

[53] 例えば、

  Wed (= Wednesday), 15 (th) Mar (March = 3rd month of year) 2002
    12 (hour):32 (minute):23 (second) (timezone =) +0900 (JST)

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

[79] RFC 2822/RFC 5322 は、

... に FWS を要求しています。また、

... には FWS を認めていますが、なくても構いません。更に、

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

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

[103] linear-white-space = FWScomment の定義は RFC 822RFC 2822/RFC 5322 で厳密には異なります。詳しくはそれぞれの項を参照してください。

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

[105] 詳しくは comment を参照してください。

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

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

曜日

[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 1036RFC 2822/RFC 5322 は正しい値であることを要求しています >>77 3.3., >>117 5.1.

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

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

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

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

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

[50] RFC 1123 は 4桁のを生成するべき >>44 5.2.14 としていました。

[51] RFC 1123 は2桁のをどう解釈するべきかは定義していません。

[52] RFC 1123 は副作用として3桁のも認めていますが、それにはまったく言及していません。 どう解釈するべきかは不明です。

[66] RFC 2183RFC 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.

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

[141] VPIMv2 を規定する RFC 3801 は2004年に出版されたにも関わらず、 2桁年号の例を示しています >>48

旧版が20世紀に出版されたものをまともにチェックせずに改訂再出版したからでしょうが...

[98] 西暦1万年問題には未対応です。

[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 5322son-of-RFC 1036 では範囲は 00 から 60 までとされており、 閏秒も反映されることになっています >>77 3.3., >>106 3.3., >>117 5.1.

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

時間帯

[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 1036ctime(3) 形式の

Wdy Mon DD HH:MM:SS YYYY
... は RFC 822 に適合しないため認められないものの、用いられているため、対応するのが良い (encouraged) >>109 としていました。

[114] RFC 1036 では Date:, Expires: で使われていました。

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

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

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

RSS 2.0 における日時

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

[140] RSS 2.0 文書に関して、 RSS Best Practices Profile は次のようなことを述べています >>5

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

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

[10] M.C.P.C.: 「RSS 簡単一発作成 『RSS 生成 CGI』」から書き出されるRSS 2.0の日付情報が不正なので直すパッチ ( 版) http://blog.dtpwiki.jp/dtp/2009/03/rss-rss-cgirss-.html
  • ○正 > "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]

SmartFormat

[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

[39] SmartFormat仕様書(Atom準拠) – SmartNews 媒体運営者サポートサイト, https://publishers.smartnews.com/hc/ja/articles/360010977833#entry

記事の公開日(フォーマットは W3CDTF に定められたものとする)

[42] Atom 1.0の日時形式W3C-DTF とは異なる。この実装は仕様違反。

[115] こんな技術的レベルが低くても SmartNews というスマートフォンアプリは普及しているのでこの形式もよく使われていると推測される。 技術レベルの高い低いと市場で成功するかどうかは無関係だとよくわかる。 不幸中の幸いなのは、この形式を処理するのは SmartNews 社内システムだけなので、 外部の一般の技術者はこの形式をどう扱うか考えなくてすむこと。 ただし社外の一般の技術者もこの形式で生成しなければならない場面はある。

文脈

[99] RFC 822の日時形式:

[102] RFC 1123の日時形式

[35] RFC 2183の日時形式は次の場面で使われています。

[143] RFC 5322の日時形式RFC 5547 が規定する SDP属性でも使われています。

Content-Disposition:引数に相当するもので、 そちらでは RFC 2183の日時形式が使われています (>>35)。

歴史

RFC 822

[88] RFC 821 - Simple Mail Transfer Protocol, , https://tools.ietf.org/html/rfc821#page-33

5. DATE AND TIME SPECIFICATION

5.1. SYNTAX

     date-time   =  [ day "," ] date time        ; dd mm yy
                                                 ;  hh:mm:ss zzz
     day         =  "Mon"  / "Tue" /  "Wed"  / "Thu"
                 /  "Fri"  / "Sat" /  "Sun"
     date        =  1*2DIGIT month 2DIGIT        ; day month year
                                                 ;  e.g. 20 Jun 82
     month       =  "Jan"  /  "Feb" /  "Mar"  /  "Apr"
                 /  "May"  /  "Jun" /  "Jul"  /  "Aug"
                 /  "Sep"  /  "Oct" /  "Nov"  /  "Dec"
     time        =  hour zone                    ; ANSI and Military
     hour        =  2DIGIT ":" 2DIGIT [":" 2DIGIT]
                                                 ; 00:00:00 - 23:59:59
     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)

5.2. SEMANTICS

          If included, day-of-week must be the day implied by the date
     specification.
          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.

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.

RFC 1123

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

5.2.14 RFC-822 Date and Time Specification: RFC-822 Section 5

         The syntax for the date is hereby changed to:
            date = 1*2DIGIT month 2*4DIGIT
         All mail software SHOULD use 4-digit years in dates, to ease
         the transition to the next century.
         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.
         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.
         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.

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; 以前はグリニッジ標準時として知られていました。訳注: 厳密には 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]
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

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" と等しいとみなすのが良いです

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

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" と等しいとみなすのが良いです

[154] RFC 3339RFC 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 メッセージ以外でもよく使われてきましたが、 IETFISO 8601 に基づいた新しい RFC 3339の日付形式提案標準として発表しました。 今後の新しい IETF protocol はこの形式に則って規定されることになります。 また、それ以外の仕様や実装でもこの新しい標準を採用するのが良いでしょう。

[69] RFC 4865SMTPDSN を拡張するものですが、 RFC 3339の日付形式を採用しています。

[101] mboxctime 形式を採用しています。

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

[100] IMAP では似て非なる形式が使われます。 IMAPの日時形式

メモ

電子メールプロトコル

[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

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

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

[148] RSS で pubDate や lastBuildDate を出力する時に気になる DATE_RFC822 や DATE_RFC2822 の違いについて | ウェブル (Weble 著, 版) http://weble.org/2011/11/30/rss-date_rfc822-and-date_rfc2822

以前ブログにメモするときに DATE_RFC822 をすれば良いと書きましたが、しっかり見てみると間違ってます。というかコメントでアドバイス頂けてるのに気付いてませんでした。正確には DATE_RFC2822 で4桁で表示しなければいけないようです。

[149] IETF差分仕様書というわかりにくい形で仕様を改訂し、 日時処理ライブラリーの開発者がなぜか元の RFC 822 形式を実装し、 ドキュメントに何を選ぶのが正しいか明確に記述しなかった、 という不幸が重なり事情を知らない開発者が混乱し、 結果ゴミデータが蔓延する、とかいう悲劇が21世紀になって10年経っても未だに続いているとかわらえない。

[151] RFC 5321 - Simple Mail Transfer Protocol ( 版) https://tools.ietf.org/html/rfc5321#section-4.4

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.

[155] RFC 5260 - Sieve Email Filtering: Date and Index Extensions () https://tools.ietf.org/html/rfc5260

[29] Git - git-commit Documentation () https://git-scm.com/docs/git-commit#git-commit-RFC2822

RFC 2822

The standard email format as described by RFC 2822, for example Thu, 07 Apr 2005 22:13:13 +0200.

[97] RFC Errata Report » RFC Editor, https://www.rfc-editor.org/errata_search.php?rfc=3297