[1] 日付を文字(数字)列で表現する方法には、古来様々な 方法が採られてきました。しかしその試みはそれぞれ 独立したものであったため、多くの場合互換性がありません。 例えば、 01/02/03 は、地域により2001年2月3日, 2003年1月2日, 2003年2月1日のように複数の解釈があり得ます。
人が書いて人が解釈していた頃は、当然混乱はあったにしろ、 文脈によりある程度使い分け・識別していました。 しかし機械が日付を扱うようになると、それに伴い表現方法は (技術的制約などで) 更に増加し、混乱は決定的なものとなりました。
電子メイルの頭の部分に記述する日付の形式です。 現在では頭は基本的に機械が処理する部分との認識・実装が 一般的ですが、かつては人が読み書きするのが当然でしたから、 斜線を使う方式での解釈の多義性が問題視されたのです。
RFC 561 の形式の上位互換のようです。 斜線を使う形式は地域により解釈が異なり得るので非推奨とされてます。
RFC 733 の形式と似ていますが、時間(hour)と分・秒の 区切りの ":" が必須となりました。
なぜか年号が2桁でなければならないように退化しています。
電子ニュース・メッセージでのRFC 1036の日付形式にそのまま 採用されました。
RFC 822 の形式の小改訂で、4桁の西暦年号が認められ、 推奨されました。また、時間帯は数値表現が推奨されています。
MIME や HTTPの日付形式でもほぼそのまま採用されています。 (RFC 3339の日付形式登場以前の) Internet 標準の日付形式と考えられていました。
RFC 822の日付形式 (RFC 1123 で改訂) と実質的に同じです。 但し新しいメッセイジに使われる形式として、より厳格な書式が 定義されています。
RFC 822の日付形式の秒の後に、1秒に満たない秒数(ってへんな いいかただけど。) が6桁分まで書ける様に拡張したものです。 RFC 1505 が普及しなかったので、この形式も普及しませんでした。
USENET では元々 ARPANET の電子メイルとは 違った形式を使っていましたが、電子ニュースのメッセージの形式自体 が RFC 822 とほとんど同じ物になったので、日付形式もそうなりました。
RFC 850の日付形式→RFC 1036の日付形式 (RFC 822の日付形式と同じ) →usefor-articleのDate:欄
ただし、電子ニュースの記事では RFC 822 とは異なり、途中での FWS や comment の自由な挿入は許されていません。 当初からほぼ RFC 2822 の obs でない構文相当でした。
HTTP/1.0 以降は RFC 822 と同じ様なメッセージ形式を使っていますから、 RFC 822の日付形式 (をやや限定したもの) を標準としていますが、標準化が遅れている間に自分の好きな形式を送る実装が多くなりすぎたために、 RFC 850の日付形式 (旧) や asctime形式も理解出来なければならず、 更にそれ以外の形式も頑張って解釈できるようにすることになっています。
HTML は歴史的な理由により様々な日付形式を併用しています。
datetime 属性や
datetime フォーム制御子では、
ISO 8601の日付形式のプロファイルを使っています。
lastModified DOM属性では
ECMAScriptの日付形式に近いものを使っています。
XML は仕様として日付形式を特に規定しているわけではありませんが、 XML 応用の中には XML Schemaの日付形式を用いているものも多々あります。
Atomの日付形式のように、「RFC 3339の日付形式かつ XML Schemaの日付形式」 のようなよくわからない定義を採用しているものもあります。
RSS は RFC 822の日付形式のプロファイルを定義しています。
ISO 8601の日付形式は、その名の通り ISO 8601 で規定された形式ですが、 ISO 8601 そのものは具体的な形式を定めず、様々な日付要素を定義して、これを組み合わせて柔軟に実際の形式を確定できるようになっています。
RFC 3339 は、 Internet の新しい標準時刻表現形式を規定しています。 これは ISO 8601 のプロファイルであり、 W3C HTML4 などで採用されている日付形式とほぼ同じものです。
XML Schema 第2部では dateTime など複数の日時に関連したデータ型を定義していますが、
その中には RFC 3339 の日付形式に似た (同じではない) 日付形式など、
ISO 8601の日付形式のプロファイルにあたるものが含まれています。
The epoch (1970年1月1日0時0分0秒 (GMT)) からの経過秒数を使うのが Un*x時間形式です。 Un*x で動作するプログラムを中心に内部処理形式・保存形式として非常に良く使われています。
[11] 閏秒が扱えないという問題がありますが、これまであまり意識されてきませんでした。
Date 物体ECMAScript は The Epoch からのミリ秒の数を Date
物体で使っています。 DOM の DOMTimeStamp
データ型もそれに倣っています。 Date
物体には toGMTString など日付を文字列に変換するメソッドが定義されています。
Microsoft 社の言語環境である Visual Basic
で日付や時刻を扱う型である Date 型の実体は浮動小数点型で、整数部で日付,
小数部で時刻を表します。
22/Jul/2002:11:57:36 +0900
[48] 最近100分の1秒単位で入るようになりました。 (名無しさん [sage] 2005-12-31 12:40:02 +00:00)
[49] >>48 (VIPでは。) (名無しさん [sage])
[50] 2006年3月31日の次は3月32日になりました。 (名無しさん 2006-03-31 16:13:50 +00:00)
[51] >>50 その翌日は4月2日でしたが、VIPなど一部の板では3月33日になりましたw (名無しさん 2006-04-01 16:15:27 +00:00)
[52]
佐賀暦2006年,2006/10/21(佐賀) 03:11:20.28 @ VIP
(佐賀県記念)
(名無しさん 2006-10-21 01:19:45 +00:00)
[53]
VIP では2007/02/13(火)
の次は2007/02/15(水)
になりました。
(名無しさん 2007-02-14 13:26:34 +00:00)
[8] ほとんどの表記法は、午前・午後の区別をせず、24時間制としています。
[9] 午前・午後を区別する場合は、真夜中と昼の0時が午前なのか午後なのか, 更に "0" 時なのか "12" 時なのかに注意する必要があります。
[12] >>9 区別しない場合においても、 "0" 時と "24" 時の扱いが問題になります。 "24:00" の存在を認めている形式もあれば、いない形式もあります。
[4] 秒は、厳密には閏秒の挿入を考慮する必要があります。 しかし計算機やネットワークの分野ではそこまでの正確性が必要とはあまりなりませんから、閏秒を無視した規格や実装がかなり多いです。
[6] 日付の表記という面では、閏秒の削除はまず問題にはなりません。 (59秒が無くなるだけだから。) 閏秒の挿入は "60" という普通とりえない値が必要になりますから、問題になります。
[5] 最近の規格, 例えば ISO 8601の日付形式は閏秒を記述出来ます。
[7] 古い規格や実装では閏秒が2秒分挿入されて "61" 秒もありうるとしているものがありますが、実際にそうした例はありませんし、この説は間違いであることが後に分かりました。 ですから、新しい規格や実装は "61" 秒を考慮する必要はありません。
[10] 秒未満 (秒の小数部) を扱える規格や実装はほとんどありませんでしたが、最近増えてきています。 例えば RFC 3339の日付形式は Internet 標準として秒未満の記述を可能にしています。 また GNU diff の出力には秒未満の欄があります。 HTMLの日付形式でも秒の小数部を記述できます。
RFC 2822, son-of-RFC 1036, usefor では数値形式を推奨。 HTTPでは文字列「GMT」固定。
非標準の時間帯文字列を使う実装がかなりあった。今は少ないと思う。 各地で観測されている時間帯を表す文字列の一覧参照。
数値形式に、注釈で文字列を添える (eg. +0900 (JST)) のが、 RFC 2822の
Received: 欄における推奨。だけど、そういうのを
Date: 欄でやると意味の分からない足し算・引き算を
やる訳の分からん実装 (Windows 95 の Microsoft Exchange らしい。)
があるという罠。
「-0000」は時間帯不明を表すという慣習があって、RFC 2822の日付形式 で明文化された。 UTC との時差が整数分にならない時もこれを 使うといいらしい。(ほんとか? ; この話はどの仕様書にも 載ってない。; ていうか整数分にならない地域ってどこよ?)
RFC 3339 にこの話も載ってます。時差が整数分にならないのは、 過去にあったけど現在はないようです。 RFC 3339 は、そうした 時間帯は他の適当な(表現可能な)時間帯に直すように指示しています。 ("-00:00" にしろとまでは言ってない。)
1970-01-01T00:00:00+00:00; 0) 以前が扱えません。 (一部、負の値を使って扱えるように拡張している実装もありますが。)[47] DCMI Date Working Group <http://www.dublincore.org/groups/date/>
[18] 将来の日付の扱いも面倒です。将来行われうる暦法の変更を我々は知り得ないからです。 おそらく最も現実的な解は、
ことくらいでしょうか。
また、情報記録用の形式に通し時 (Un*xtime やユリウス日など) ではなく ISO 8601 のような人間可読形式を採用するのも良い考えかもしれません。 2003年1月1日の (365*100+閏日の数) 日後が2103年1月1日になる保証はありませんからね。
10000-02-31 みたいなデータは、もし処理系に余裕があるなら、内部形式に変換して外部形式に再変換した時にも 10000-02-31 に戻ってくるのがいい気がします。まあ実際にはそんなこと考えてもいられないでしょうし、考える必要もあまりないでしょうけど。
Date::Calc とかが定番ですかね。