[1] 日時形式、すなわち日付を文字(数字)列で表現する方法については、古来様々な 方法が用いられてきました。しかしそれは多くの場合互換性がありません。 例えば、 01/02/03 は、地域により2001年2月3日, 2003年1月2日, 2003年2月1日のように複数の解釈があり得ます。
人が書いて人が解釈していた頃は、当然混乱はあったにしろ、 文脈によりある程度使い分け・識別していました。 しかし機械が日付を扱うようになると、それに伴い表現方法は (技術的制約などで) 更に増加し、混乱は決定的なものとなりました。
[55] 本項は主として日時を記述する構文 (記号列) に焦点を当てたものです。 日時を表示するという行為やどのような日時要素を表示するかの選択に関しては、 日時表示を参照。
[45] メールやHTTPなどの情報交換プロトコルでは、伝統的にテキスト形式が用いられているため、 日時の表記もテキスト形式でした。メールを手元のディスクに保存する時など長期保存するときも、 このテキスト形式をそのまま用いることがよくあります。
[46] しかし比較その他の処理を行いたい時はテキスト形式のままでは複雑すぎるので、 構文解析したデータを内部的には使うのが普通です。 2003年1月2日をリスト (2003, 1, 2) のようなデータ構造で扱うのでも良いのですが、それでもまだ複雑なので、 「1970年1月1日からの秒数」など基準を決めて数値化するのが普通です。
[63] プログラミング言語のライブラリーやデータベースの API などは日時を扱うデータ型を用意していて、こうした内部表現と外部表現との変換を行ったり、 内部表現同士の演算を行ったりできるのが普通です。
電子メイルの頭の部分に記述する日付の形式です。 現在では頭は基本的に機械が処理する部分との認識・実装が 一般的ですが、かつては人が読み書きするのが当然でしたから、 斜線を使う方式での解釈の多義性が問題視されたのです。
RFC 561 の形式の上位互換のようです。 斜線を使う形式は地域により解釈が異なり得るので非推奨とされてます。
RFC 724 の英月名形式とほぼ同じ物です。
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 でない構文相当でした。
[61] Web は歴史的な理由により様々な日付形式を併用しています。
datetime 属性や
datetime フォーム制御子では、
ISO 8601の日付形式のプロファイルを使っています。
lastModified DOM属性では
ECMAScriptの日付形式に近いものを使っています。
HTTP/1.0 以降は RFC 822 と同じ様なメッセージ形式を使っていますから、 RFC 822の日付形式 (をやや限定したもの) を標準としていますが、標準化が遅れている間に自分の好きな形式を送る実装が多くなりすぎたために、 RFC 850の日付形式 (旧) や asctime形式も理解出来なければならず、 更にそれ以外の形式も頑張って解釈できるようにすることになっています。
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の日付形式のプロファイルにあたるものが含まれています。
[75] ANSI C の asctime() の日付形式です。 C や perl などでは非常に手軽に扱うことが出来るので、よく使われます。このためHTTPの日付形式にも含まれています。
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 型の実体は浮動小数点型で、整数部で日付,
小数部で時刻を表します。
[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)
[90] 機械処理用に限らず日付の表記においては月と日の順序問題による混乱を防ぐため、 月番号ではなく月名の表記が好ましいとされる場合があります。
[91] 例えば RFC 822の日時形式は実際に3文字の英語の省略形の月名を使っています。
[8] ほとんどの表記法は、午前・午後の区別をせず、24時間制としています。
[9] 午前・午後を区別する場合は、真夜中と昼の0時が午前なのか午後なのか, 更に "0" 時なのか "12" 時なのかに注意する必要があります。
[12] >>9 区別しない場合においても、 "0" 時と "24" 時の扱いが問題になります。 "24:00" の存在を認めている形式もあれば、いない形式もあります。
[17] 起き続けている間を論理日として、翌日の午前 n 時をその日の (n + 24) 時と呼ぶ人もいます。例えば翌日午前2時が26時となります。
[79] 正確な日時が不明である時、人間向けであれば「約」や「頃」や「?」や 「○日から○日」のように日時の記述の前後で補足したり、時間間隔として記述したりします。
[80] 機械向けの場合、分まで、日までといった精度の低い構文を選択的に用いたり、 始点と終点の組の時間間隔として記述したりします。
[81] 正確な日時が不明であることを記述したり、推定される範囲を記述したりできる日時形式として、 EDTF や TEMPER があります。
1970-01-01T00:00:00+00:00; 0) 以前が扱えません。 (一部、負の値を使って扱えるように拡張している実装もありますが。)[47] DCMI Date Working Group <http://www.dublincore.org/groups/date/>
[59] 計算機処理では、グレゴリオ暦を過去に延長した先発グレゴリオ暦、 先発UTCを用いることが多いです。
[86] tzdata は過去のデータも資料の発見に基づきしばしば改訂されています。 過去の歴史的事象の記述のために当地で記録されている日時を現在の当地の時間帯に基づき先発UTCに変換して保持していると、 後から tzdata が改訂された時に、元の想定とは違う値に変化してしまうことがあります。
[87] 例えば時間帯 R/S で西暦1234年の時差が +01:23 と定義されていたとします。
の出来事を記録するため、
1234-05-06T00:00:00+01:23 すなわち
1234-05-05T22:37:00Z という先発UTCの値を使うことにします。
表示の際に、 R/S に変換して日付だけ取って とします。
その後、 R/S の西暦1234年の時差が +01:20 に変更された時、
この値は
1234-05-05T23:57:00+01:20 ですから、
日付だけ使うと になり、1日ずれてしまいます。
[89] 時間帯の分割などがあると、 tzdata でも新たな識別子が追加されます。 tzdata を使うプラットフォームの利用者は新設時間帯に属するなら、 新しい識別子に設定を変更することになります。 すると過去の日時について、同様の“変化”が起こることになります。
[58] ある時刻からある時刻までの範囲や、特定の時刻を想定しない時間の長さを表す書式もいろいろあります。 次の各項を参照。
[93] 文字列としての整列が日時としての整列になることを極めて重視して設計された日時形式として、 例えばRFC 2550の日時形式があります。
[94] そうした配慮がなければ、一般には日時の整列には特別な処理が必要です。
[95] ISO 8601の日時形式とその派生形式各種は、実用的な範囲内では文字列としての整列が日時としての整列となる場合が多いです。 (例えば1万年以上の日時などでそれが崩れます。)
Date::Calc とかが定番ですかね。[54] OASIS CAM V1.1 Specification ( ( 版)) <http://docs.oasis-open.org/cam/v1.1/os/OASIS-CAM-Specification-1_1-015-060107.html>
[65] データ連携と統合を科学するブログ: グレゴリオ暦?ユリウス暦? データベースによって異なる、日付時刻型が扱える範囲 ( 版) <http://bitdatasci.blogspot.jp/2014/12/blog-post.html>
A site may provide date information implicitly, relying on Google's estimated page date feature to detect dates embedded in the page URL, title or other features, or explicitly, by supplying a date in a structured data format. In either case, effective use of dates requires formatting the dates correctly.
For Custom Search's Sort by Attribute, Bias by Attribute, Restrict to Range features, Google attempts to parse dates using both conventional date formatting and formal standards such as ISO 8601 <http://en.wikipedia.org/wiki/ISO_8601> and IETF RFC 850 <http://www.faqs.org/rfcs/rfc822.html>. The following complete date formats are accepted:
Date Format Example Date
YYYY-MM-DD 2009-12-31
YYYY/MM/DD 2009/12/31
YYYYMMDD 20091231
Month DD YYYY December 31 2009
DD Month YYYY 31 December 2009
Google will attempt to parse variants of these date formats, such as MM/DD/YYYY and DD/MM/YYYY. However, the more ambiguous the date, the less likely that Google will parse it correctly. For example, the date 06/07/08 is extremely ambiguous and it is unlikely Google will assign to it the interpretation you want. For best results, use a complete ISO 8601 date format with a fully specified year.
アメリカで働いている知人によると、「社内で共有するファイルは、必ずファイル名の先頭に日付をいれているんだけど、『月、日、年』の順番で書くから、フォルダに並んでいるファイルが古い順に並ばなくて不便」
[68] 15114 – forms: new <input> type for YYYY / YYYY-MM / YYYY-MM-DD / YYYY-MM-DD hh:mm, at user's choice ( 版) <https://www.w3.org/Bugs/Public/show_bug.cgi?id=15114>
[66] SAS日付関連のフォーマット,インフォーマット - CatTail Wiki* ( 版) <http://wikiwiki.jp/cattail/?SAS%C6%FC%C9%D5%B4%D8%CF%A2%A4%CE%A5%D5%A5%A9%A1%BC%A5%DE%A5%C3%A5%C8%A1%A4%A5%A4%A5%F3%A5%D5%A5%A9%A1%BC%A5%DE%A5%C3%A5%C8>
月末を意味する日に99日というのはよくありますよね。
2007/02/99
ただ月末を31日にするのには困りました。
2007/02/31
A site may provide date information implicitly, relying on Google's estimated page date feature to detect dates embedded in the page URL, title or other features, or explicitly, by supplying a date in a structured data format. In either case, effective use of dates requires formatting the dates correctly.
For Custom Search's Sort by Attribute, Bias by Attribute, Restrict to Range features, Google attempts to parse dates using both conventional date formatting and formal standards such as ISO 8601 and IETF RFC 850. The following complete date formats are accepted:
Date Format Example Date
YYYY-MM-DD 2009-12-31
YYYY/MM/DD 2009/12/31
YYYYMMDD 20091231
Month DD YYYY December 31 2009
DD Month YYYY 31 December 2009
Google will attempt to parse variants of these date formats, such as MM/DD/YYYY and DD/MM/YYYY. However, the more ambiguous the date, the less likely that Google will parse it correctly. For example, the date 06/07/08 is extremely ambiguous and it is unlikely Google will assign to it the interpretation you want. For best results, use a complete ISO 8601 date format with a fully specified year.
[6] Representations of local time of the day for information interchange ... - Full View | HathiTrust Digital Library | HathiTrust Digital Library () <https://babel.hathitrust.org/cgi/pt?id=uiug.30112104151292;view=1up;seq=1;size=150>
MH-SDTT の start_time 及び送出系の時間管理はサマータイム制の実施の有無に関わらず、常
に「UTC(世界標準時)+9 時間」を基準とする。
[60] 過去の年月日の表記の統一 - Uyopedia () <http://uyopedia.a.freewiki.in/index.php/%E9%81%8E%E5%8E%BB%E3%81%AE%E5%B9%B4%E6%9C%88%E6%97%A5%E3%81%AE%E8%A1%A8%E8%A8%98%E3%81%AE%E7%B5%B1%E4%B8%80>
[20] モンゴル語 文法 時間の点と幅の表現:解説 () <http://www.coelang.tufs.ac.jp/mt/mn/gmod/contents/explanation/055.html>
[21] 日付定数 () <http://wiki.genexus.jp/hwiki.aspx?%E6%97%A5%E4%BB%98%E5%AE%9A%E6%95%B0,>
[43] 天泣記 (Tanaka Akira著, ) <http://www.a-k-r.org/d/2012-10.html>
due_dateoptional, string
Expected date of finalization. Format mm-dd-yyyy.
[88] 15114 – forms: new <input> type for YYYY / YYYY-MM / YYYY-MM-DD / YYYY-MM-DD hh:mm, at user's choice () <https://www.w3.org/Bugs/Public/show_bug.cgi?id=15114>