[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
に対応しているのかは謎です。
- ○正 > "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]
[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
記事の公開日(フォーマットは W3CDTF に定められたものとする)
[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
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)
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.
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.
[45] RFC 1123 は、 RFC 822 の日時の部分の一部を改訂しています。
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.
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つの間隔を使用することを推奨します。 古い実装は折畳み空白間隔を正しく解釈しないかもしれません。
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 の中になければなりません。
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-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 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
RSS2.0の日付もRFC 3339になっているケースが割とありました。
以前ブログにメモするときに DATE_RFC822 をすれば良いと書きましたが、しっかり見てみると間違ってます。というかコメントでアドバイス頂けてるのに気付いてませんでした。正確には DATE_RFC2822 で4桁で表示しなければいけないようです。
[149] IETF が差分仕様書というわかりにくい形で仕様を改訂し、 日時処理ライブラリーの開発者がなぜか元の RFC 822 形式を実装し、 ドキュメントに何を選ぶのが正しいか明確に記述しなかった、 という不幸が重なり事情を知らない開発者が混乱し、 結果ゴミデータが蔓延する、とかいう悲劇が21世紀になって10年経っても未だに続いているとかわらえない。
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
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