[1] 日時形式、 すなわち日付や時刻の表現については、 古来様々な方法が用いられてきました。しかしそれは多くの場合互換性がありません。 例えば、 01/02/03 は、地域により, , , のように複数の解釈があり得ます。
人が書いて人が解釈していた頃は、当然混乱はあったにしろ、 文脈によりある程度使い分け・識別していました。 しかし機械が日付を扱うようになると、それに伴い表現方法は (技術的制約などで) 更に増加し、混乱は決定的なものとなりました。
[55] 本項は主として日時を記述する構文 (記号列) に焦点を当てたものです。 日時を表示するという行為やどのような日時要素を表示するかの選択に関しては、 日時表示を参照。
[45] メールやHTTPなどの情報交換プロトコルでは、伝統的にテキスト形式が用いられているため、 日時の表記もテキスト形式でした。メールを手元のディスクに保存する時など長期保存するときも、 このテキスト形式をそのまま用いることがよくあります。
[46] しかし比較その他の処理を行いたい時はテキスト形式のままでは複雑すぎるので、 構文解析したデータを内部的には使うのが普通です。 をリスト (2003, 1, 2) のようなデータ構造で扱うのでも良いのですが、それでもまだ複雑なので、 「からの秒数」 など基準を決めて数値化するのが普通です。
[63] プログラミング言語のライブラリーやデータベースの API などは日時を扱うデータ型を用意していて、こうした内部表現と外部表現との変換を行ったり、 内部表現同士の演算を行ったりできるのが普通です。
[48] 電子メイルの頭の部分に記述する日付の形式です。 現在では頭は基本的に機械が処理する部分との認識・実装が 一般的ですが、かつては人が読み書きするのが当然でしたから、 斜線を使う方式での解釈の多義性が問題視されたのです。
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の日付形式にも含まれています。
[11]
Unix Epoch からの経過秒数を使うのが
Un*x時間形式です。
Un*x で動作するプログラムを中心に内部処理形式・保存形式として非常に良く使われています。
情報交換でもよく用いられています。
Date
物体ECMAScript は The Epoch からのミリ秒の数を Date
物体で使っています。 DOM の DOMTimeStamp
データ型もそれに倣っています。 Date
物体には toGMTString
など日付を文字列に変換するメソッドが定義されています。
[52] プロトコルの数だけ日時形式もあるのではないかと思うくらい、 驚くほどたくさんの日時形式が使われています。
[53] そしてプログラミング言語の数だけ違った日時データ型があります。 「日付」と「時刻」と「日時」など、同じ言語で複数のデータ型があるケースも珍しくありません。 同じ言語の同じ型でも、動作するプラットフォームによって仕様が変わってくる厄介なケースもあります。
[51] INBUDS Technical Notes, , https://web.archive.org/web/20030406153700/http://www.inbuds.net/jpn/tech.html
- 発行年月日
- 発行年月日は8桁(YYYYMMDD)で表現する。月日が不明な場合は「00」。
[59] INBUDS Technical Notes, , https://www.inbuds.net/jpn/tech.html
- 発行年月日
- 発行年月日は8桁(YYYYMMDD)で表記する。
[71] 地方公共団体情報システムデータ要件・連携要件標準仕様書【第2.0版】 - 20230330_local_governments_16.pdf, , https://www.digital.go.jp/assets/contents/node/basic_page/field_ref_resources/c58162cb-92e5-4a43-9ad5-095b7c45100c/a810f063/20230330_local_governments_16.pdf#page=10
[81] 参考_マイナンバーカード交付申請書等作成事業者向け運用保守手引書 rev2 - bid_03_11-05.pdf, , https://www.kumamoto-kouikirengo.jp/information/pdf/bid_03_11-05.pdf#page=11
[87] A9t5dao4_134rcrp_eco.tmp - 000898351.pdf, , https://www.soumu.go.jp/main_content/000898351.pdf#page=19
[89] A9zn2isg_6pd1e9_a9o.tmp - 000898352.pdf, , https://www.soumu.go.jp/main_content/000898352.pdf#page=28
[97] 000898520.pdf, , https://www.soumu.go.jp/main_content/000898520.pdf#page=37
[73] format2.pdf, , https://www.chibabank.co.jp/webeb/Contents_bizsol/manual/pdf/format2.pdf#page=1
ファイル作成日(和暦)/年月日(YYMMDD)
#page=5
表示形式:"YYYY-MM-DDT00:00:00"(時刻部分はALL0)
[98] Microsoft Word - V15_0_0 中表紙.doc - 200806_CI-NET 標準ビジネスプロトコル(Ver 1.5).pdf, , https://www.kensetsu-kikin.or.jp/database/pdf/200806_CI-NET%20%E6%A8%99%E6%BA%96%E3%83%93%E3%82%B8%E3%83%8D%E3%82%B9%E3%83%97%E3%83%AD%E3%83%88%E3%82%B3%E3%83%AB(Ver%201.5).pdf#page=59
[99] 【第五章 出荷案内システム Ver4】 - sys05_v4.pdf, , http://nsk.c.ooco.jp/edi/sys05_v4.pdf#page=25
[100] 電気通信研究所研究実用化報告 19(1), 特許情報部資料部門, , , https://dl.ndl.go.jp/pid/2310917/1/26 (要登録)
[101] 【保育士雇用者】保育士特定登録取消者管理システムマニュアル.pdf, , https://d5h000008nidkeag.my.salesforce.com/sfc/dist/version/download/?oid=00D5h000008NIdk&ids=0685h00000UVWIPAA5&d=/a/5h000001VML3/ofR_iixkviNM.g_HKNTm8jrlyE_kckRKqQKqqx3WVl0&operationContext=DELIVERY&viewId=05HJ2000000c6zaMAA&dpt=
※生年月日はYYYY/M/D(例:2000/1/1)形式である
必要があります。
※他ファイル等から貼り付けを行う場合は、下記手順に従い必ず
値貼り付けをしてください。貼り付け元の生年月日の記載方式は 「H8.1.1」または「平成8年1月1日」に限ります。
[30] 月: 情報交換用日付形式は一般に認めていませんが、1月、2月、3月を前年の13月、14月。15月にすると年度の関係で扱いがよくなることがあります。予定管理系ソフトウェア(謎)などでは採用の検討に値するでしょう。 (ツェラーの公式なんかもこの方法を使いますね。)
[31] 人が読む日付形式では、 (特に欧米で) 月名 (数字ではなく。) を使うのが好まれることがあります。例えば、 ISO 8601の日付形式 の 2003-01-02 よりも RFC 2822の日付形式の 02 Jan 2003 の方が良いという人もいます。これは、欧米では >>1 に挙がっている解釈の多義性が大きな問題だからです。4桁年号と月の名前と日付の数字なら、解釈は明らかです。
[90] 機械処理用に限らず日付の表記においては月と日の順序問題による混乱を防ぐため、 月番号ではなく月名の表記が好ましいとされる場合があります。
[91] 例えば RFC 822の日時形式は実際に3文字の英語の省略形の月名を使っています。
[8] ほとんどの表記法は、午前・午後の区別をせず、24時間制としています。
[9] 午前・午後を区別する場合は、真夜中と昼の0時が午前なのか午後なのか, 更に "0" 時なのか "12" 時なのかに注意する必要があります。
[12] >>9 区別しない場合においても、 "0" 時と "24" 時の扱いが問題になります。 "24:00" の存在を認めている形式もあれば、いない形式もあります。
[17] 起き続けている間を論理日として、翌日の午前 n 時をその日の (n + 24) 時と呼ぶ人もいます。例えば翌日午前2時が26時となります。
[74] Xユーザーの眼精疲労さん: 「@fumokmm これ混在してて相当苦しんだ 時間については午前午後を1と2で分けてあったり… 会社の長老に聞かにゃわからんてw」 / X, , https://twitter.com/zawaji_rainfall/status/1698520318044709212
[13]
「9年8月(日不明)」
や
「8年9月10日頃」
や
「12時34分 (時間帯不明)」
など曖昧な日時の記述が必要なこともあります。
[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
[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
[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
[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
[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
[37] () http://www.moe.gov.cn/ewebeditor/uploadfile/2015/01/13/20150113091154536.pdf
[27] これ京都?いいえ、コソボです。ヨーロッパなのにどう見ても日本な景観が話題に「木造ってだけでこんなに似るのか」 - Togetter () https://togetter.com/li/1392976#c6703160
[29] () https://cio.go.jp/sites/default/files/uploads/documents/1015-1_gyousei_data_model_datetime_20200514.pdf
[34] Wayback Machine () https://web.archive.org/web/20200411150338/https://cio.go.jp/sites/default/files/uploads/documents/1015-1_gyousei_data_model_datetime.pdf
[35] () https://cio.go.jp/sites/default/files/uploads/documents/1015-1_gyousei_data_model_datetime.pdf
[38] () https://cio.go.jp/sites/default/files/uploads/documents/gyouseidata_hidukejikoku.pdf
[39] [Android] 端末の言語を変更後「プライバシーポリシーの改定」が再表示される · Issue #49 · cocoa-mhlw/cocoa · GitHub, https://github.com/cocoa-mhlw/cocoa/issues/49
[42] 各種日付がロケール依存のフォーマットで保存される · Issue #51 · cocoa-mhlw/cocoa · GitHub, https://github.com/cocoa-mhlw/cocoa/issues/51
1例として、ISO 8601 に定義される表記として、以下の形式を提案します。(強い拘りはないので固定できれば何でも良いです) https://ja.wikipedia.org/wiki/ISO_8601#%E3%82%BF%E3%82%A4%E3%83%A0%E3%82%BE%E3%83%BC%E3%83%B3%E6%8C%87%E5%AE%9A%E5%AD%90
YYYY/MM/DDThh:mm:ssZ
[47] 接触確認アプリCOCOA、地域ごとの日付フォーマットの違いで利用日数が狂う新たな不具合 | スラド オープンソース, https://opensource.srad.jp/story/21/03/14/166238/
[83] この種の話になると必ず >>82 のようなことを言い出す蛮族がいるが、世界は広く文化は多様。 欧米風に「価値観をアップデート」することが「文明化」と呼ばれた20世紀を経てもなお、 その欧米の実情が >>77 なんだよなあ。
[86] こういう謎の誤解を招く ISO 8601 信者は罪深い。
[79] Xユーザーの教育ローマ字とかさん: 「Twitter で日付検索する時、コマンドは until: だったかなあまではだいたい一回で当たるんだけど、日付が 2023-09-28 っていうハイフンで区切って年・月・日の順に並べて月と日は2桁っていうルールがなかなか覚えられなくて毎回苦労する」 / X, , https://twitter.com/awesomenewways/status/1735247114941419850
[80] 一部の日本人IT技術者は ISO 8601 形式は誰にでも簡単と信じ込んでいるが、 そうではないこういう人は意外と多いように見える。