192.txt

[1] [DFN[[RUBY[日][にち]][RUBY[時][じ]][RUBY[形][けい]][RUBY[式][しき]]]]、
すなわち[[日付]]や[[時刻]]の[[表現]]については、
古来様々な方法が用いられてきました。しかしそれは多くの場合互換性がありません。
例えば、 01/02/03 は、地域により[TIME[2001年2月3日][2001-02-03]],
[TIME[2003年1月2日][2003-01-02]],
[TIME[2003年2月1日][2003-02-01]],
[TIME[平成元年2月3日][1989-02-03]]のように複数の解釈があり得ます。

人が書いて人が解釈していた頃は、当然混乱はあったにしろ、
文脈によりある程度使い分け・識別していました。
しかし機械が日付を扱うようになると、それに伴い表現方法は
(技術的制約などで) 更に増加し、混乱は決定的なものとなりました。

* 日時の表示

[55] 本項は主として[[日時]]を記述する構文 (記号列) に焦点を当てたものです。
[[日時]]を表示するという行為やどのような[[日時]]要素を表示するかの選択に関しては、
[[日時表示]]を参照。

* 内部表現と外部表現

[45] [[メール]]や[[HTTP]]などの情報交換プロトコルでは、伝統的に[[テキスト]]形式が用いられているため、
[[日時]]の表記もテキスト形式でした。[[メール]]を手元のディスクに保存する時など長期保存するときも、
このテキスト形式をそのまま用いることがよくあります。

[46] しかし比較その他の処理を行いたい時は[[テキスト]]形式のままでは複雑すぎるので、
構文解析したデータを内部的には使うのが普通です。 
[TIME[西暦2003年1月2日][2003-01-02]]を[[リスト]] (2003, 1, 2)
のようなデータ構造で扱うのでも良いのですが、それでもまだ複雑なので、
「[[[TIME[1970-01-01]]からの秒数][Unix time]]」
など[[基準を決めて数値化する][整数時刻系]]のが普通です。

[63] [[プログラミング言語]]の[[ライブラリー]]や[[データベース]]の [[API]]
などは[[日時]]を扱うデータ型を用意していて、こうした内部表現と外部表現との変換を行ったり、
内部表現同士の演算を行ったりできるのが普通です。

[EG[
[64] [[JavaScript]] には [CODE(JS)@en[[[Date]]]] [[オブジェクト]]があります。
内部的には[TIME[1970-01-01]]からの[[ミリ秒]]数で表現されていますが、
テキスト形式で入出力でき、また[[年月日]]等各部分の数値を取得したり、
[[曜日]]を求めたりもできます。
]EG]

* 電子メイルの日付形式

[48] 
[[電子メイル]]の[[頭]]の部分に記述する日付の形式です。
現在では頭は基本的に機械が処理する部分との認識・実装が
一般的ですが、かつては人が読み書きするのが当然でしたから、
斜線を使う方式での解釈の多義性が問題視されたのです。

[SEE[ 詳細は[[インターネットメールの日時形式]] ]]

- [23] 電子メイル・電子ニュースの日付形式は長く混乱していて、どの仕様にも合致しない形式がかなり多く使われていました。その一端の''とっても簡単な''調査結果: ''EMail Msg <199312160130.TAA09527@austin.BSDI.COM>'' <http://ksi.cpsc.ucalgary.ca/archives/WWW-TALK/www-talk-1993q4.messages/869.html>
- [24] >>23 簡単な調査でこれだけ見つかるんですから、実際にはこの2,3倍の変種があった可能性があります。
[[#comment]]


** [[RFC 561の日付形式]]

- 24 JUL 1973 1527-PDT 
- 7/27/1973 1527-PDT


** [[RFC 724の日付形式]]

- 26 August 1976 1429-EDT 
- Wednesday, 8/31/76 1251-Z 

RFC 561 の形式の上位互換のようです。
斜線を使う形式は地域により解釈が異なり得るので非推奨とされてます。


** [[RFC 733の日付形式]]

- 26 Aug 76 1429 EDT

RFC 724 の英月名形式とほぼ同じ物です。


** [[RFC 822の日付形式]]

- 26 Aug 76 14:29:01 EDT

RFC 733 の形式と似ていますが、時間(hour)と分・秒の
区切りの ":" が必須となりました。

なぜか年号が2桁でなければならないように退化しています。

電子ニュース・メッセージでの[[RFC 1036の日付形式]]にそのまま
採用されました。


** [[RFC 1123 の日付形式]]

- Fri, 15 Mar 2002 16:53 +0900

RFC 822 の形式の小改訂で、4桁の西暦年号が認められ、
推奨されました。また、[[時間帯]]は数値表現が推奨されています。

[[MIME]] や [[HTTPの日付形式]]でもほぼそのまま採用されています。
([[RFC 3339の日付形式]]登場以前の) Internet 
標準の日付形式と考えられていました。


** [[RFC 2822の日付形式]] (822形式の subset)

[[RFC 822の日付形式]] (RFC 1123 で改訂) と実質的に同じです。
但し新しいメッセイジに使われる形式として、より厳格な書式が
定義されています。


** [[RFC 1505の日付形式]]

[[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 でない構文相当でした。

* Webの日時形式

[61] [[Web]] は歴史的な理由により様々な[[日付形式]]を併用しています。
[CODE(HTMLa)@en[[[datetime]]]] [[属性]]や
[CODE(HTML)@en[[[datetime]]]] [[フォーム制御子]]では、
[[ISO 8601の日付形式]]の[[プロファイル]]を使っています。
[CODE(DOMa)@en[[[lastModified]]]] [[DOM属性]]では
[[ECMAScriptの日付形式]]に近いものを使っています。

;; 詳細は[[Webの日時形式]]を参照。

** [[HTTPの日付形式]]

[[HTTP/1.0]] 以降は RFC 822 
と同じ様なメッセージ形式を使っていますから、
[[RFC 822の日付形式]] (をやや限定したもの) 
を標準としていますが、標準化が遅れている間に自分の好きな形式を送る実装が多くなりすぎたために、
[[RFC 850の日付形式]] (旧) や [[asctime形式]]も理解出来なければならず、
更にそれ以外の形式も頑張って解釈できるようにすることになっています。

* [[XMLの日付形式]]

[[XML]] は仕様として[[日付形式]]を特に規定しているわけではありませんが、
[[XML]] [[応用]]の中には [[XML Schemaの日付形式]]を用いているものも多々あります。

[[Atomの日付形式]]のように、「[[RFC 3339の日付形式]]かつ [[XML Schemaの日付形式]]」
のようなよくわからない定義を採用しているものもあります。

[[RSS]] は [[RFC 822の日付形式]]の[[プロファイル]]を定義しています。

* [[ISO 8601の日付形式]]

[[ISO 8601の日付形式]]は、その名の通り [[ISO 8601]] 
で規定された形式ですが、 [[ISO 8601]] 
そのものは具体的な形式を定めず、様々な日付要素を定義して、これを組み合わせて柔軟に実際の形式を確定できるようになっています。


** [[RFC 3339の日付形式]]

[[RFC 3339]] は、 Internet の新しい標準時刻表現形式を規定しています。
これは [[ISO 8601]] のプロファイルであり、 W3C [[HTML4]]
などで採用されている日付形式とほぼ同じものです。

** [[XML Schemaの日付形式]]

[[XML Schema]] 第2部では [CODE(XML)@en[[[dateTime]]]] など複数の[[日時]]に関連した[[データ型]]を定義していますが、
その中には [[RFC 3339]] の日付形式に似た (同じではない) [[日付形式]]など、
[[ISO 8601の日付形式]]の[[プロファイル]]にあたるものが含まれています。


* [[asctime形式]]

[75] [[ANSI]] [[C]] の asctime() の日付形式です。
[[C]] や [[perl]] などでは非常に手軽に扱うことが出来るので、よく使われます。このため[[HTTPの日付形式]]にも含まれています。


* Unix time

[11] 
[[Unix Epoch]] からの経過[[秒]]数を使うのが
[[Un*x時間]]形式です。
[[Un*x]] で動作するプログラムを中心に内部処理形式・保存形式として非常に良く使われています。
[[情報交換]]でもよく用いられています。
[SEE[ [[Unix time]]


* [[ECMAScript]] の [CODE(JS)@en[[[Date]]]] [[物体]]

[[ECMAScript]] は The Epoch からの[[ミリ秒]]の数を [CODE(JS)@en[[[Date]]]]
[[物体]]で使っています。 [[DOM]] の [CODE(JS)@en[[[DOMTimeStamp]]]]
[[データ型]]もそれに倣っています。 [CODE(JS)@en[[[Date]]]]
[[物体]]には [CODE(JS)@en[[[toGMTString]]]] など[[日付]]を[[文字列]]に変換する[[メソッド]]が定義されています。


* その他の情報交換用日時形式とプログラミング言語の日時データ型


[52] 
[[プロトコル]]の数だけ[[日時形式]]もあるのではないかと思うくらい、
驚くほどたくさんの[[日時形式]]が使われています。

[53] 
そして[[プログラミング言語]]の数だけ違った[DFN[日時データ型]]があります。
「日付」と「時刻」と「日時」など、同じ言語で複数の[[データ型]]があるケースも珍しくありません。
同じ言語の同じ型でも、動作する[[プラットフォーム]]によって仕様が変わってくる厄介なケースもあります。


[FIG(short list)[ [36] [[プログラミング言語]]や[[プラットフォーム]]の[[日時形式]], その他の[[情報交換]]用[[日時形式]] 
- [[RFC 2550の日時形式]]
- [[TLEの日時形式]]
- [[MARCの日時形式]]
- [[EDTF]]
- [[TEMPER]]
- [[XMPPの日時形式]]
- [[DateTime Wire Format]]
- [[ARINC 424-17の日時形式]]
- [[ISO 2014]]
- [[When.exe Standard Representation]]
- [[元期形式]]
- [[VRMLの日時形式]]
- [[JATSの日時形式]]
- [[GTFSの日時形式]]
- [[e-Statの日時形式]]
- [[DICOMの日時形式]]
- [[TEIの日時形式]]
- [CODE[LONGDATETIME]]
- [[PDFの日時形式]]
- [[Compact Time Format]]
- [CODE[dc:date]]
- [[RFC 867]]
- [[RFC 868]]
- [[ACTS]]
- [[FTPメールの日時形式]]
- [[MARSの日時形式]]
- [[RFC 1357の日時形式]]
- [[[CODE[<date>]] (RPSL)]]
- [[[CODE[<date>]] (RFC 2629)]]
- [[クレジットカード有効期限]]
- [[IOTPの日時形式]]
- [[IRCの日時形式]]
- [[SDMLの日時形式]]
- [[SNMPの日時形式]]
- [[ICMP Timestamp]]
- [[IP Timestamp]]
- [[TCP Timestamps]]
- [[NNTPの日時形式]]
- [[XFAの日時形式]]
- [[ACAPの日時形式]]
- [[syslogの日時形式]]
- [[P3Pの日時形式]]
- [[SNQPの日時形式]]
- [[RWhoisの日時形式]]
- [[IMAPの日時形式]]
- [[ASN.1の日時形式]]
- [[FTPの日時形式]]
- [[results file]]
- [[ARIB TR-B39]]
- [[ARIB STD-B5]]
- [[おもちゃ花火への製造年月日の記号による表示方式]]
- [[When.exe Standard Expression]]
- [[富士通の日時形式]]
- [CODE[tm]]
- [CODE[timespec]]
- [[JavaScriptの日付形式]]
- [[MySQLの日付形式]]
- [[Exifの日時形式]]
- [[GPS時]]
- [[TAI64]]
- [[SQLの日時形式]]
- [[DOS date/time format]]
- [[記憶媒体の日時形式]]
- [CODE[UTCTime]]
- [CODE[GeneralizedTime]]
- [CODE[$H]]
- [[FATの日時形式]]
- [[HFS time]]
- [[YANGの日時形式]]
- [[VMSの日時形式]]
- [[MUMPSの日時形式]]
- [[[CODE[Time]] (Ruby)]]
- [CODE[DateTime.pm]]
- [[Common Lispの日時]]
- [[ISO/IEC 11404の日時形式]]
- [[SensorMLの日時形式]]
- [CODE[:GeneralDateTimeDescription]]
- [[COBOL日時]]
- [[ARPAインターネット初期の日時]]
- [[Delphiの日時形式]]
- [[[CODE[TDate]] (CLASSLIB)]]
- [[[CODE[Date]] (Visual Basic)]]
- [[Perlにおける日時]]
- [[日立の日時形式]]
- [[Sailthruの日時形式]]
- [[東洋学文献類目の日時形式]]
- [[TOPS-10の日時形式]]
- [[FIPAの日時]]
- [[Domain/OSの日時]]
- [[Deep Impactの日時]]
- [[SISTの日時形式]]
- [[地図XML]]
- [[BSONにおける日時]]
- [[7date]]
- [[DiscordのSnowflake ID]]
- [[Pick OS日付]]

]FIG]


[51] [CITE@ja[INBUDS Technical Notes]], [TIME[2023-07-29T04:21:39.000Z]], [TIME[2003-04-06T15:40:27.971Z]] <https://web.archive.org/web/20030406153700/http://www.inbuds.net/jpn/tech.html>

>
:発行年月日 	:発行年月日は8桁(YYYYMMDD)で表現する。月日が不明な場合は「00」。

[59] [CITE[INBUDS Technical Notes]], [TIME[2023-06-02T06:40:17.000Z]], [TIME[2023-07-29T04:22:23.441Z]] <https://www.inbuds.net/jpn/tech.html>

>
:発行年月日	:発行年月日は8桁(YYYYMMDD)で表記する。

;; [70] 不明は解消された? 

[71] [CITE[地方公共団体情報システムデータ要件・連携要件標準仕様書【第2.0版】 - 20230330_local_governments_16.pdf]], [TIME[2023-03-30T07:00:57.000Z]], [TIME[2023-08-18T16:36:48.870Z]] <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>

[73] [CITE[format2.pdf]], [TIME[2021-10-29T08:00:14.000Z]], [TIME[2023-09-05T03:43:36.617Z]] <https://www.chibabank.co.jp/webeb/Contents_bizsol/manual/pdf/format2.pdf#page=1>

>[L[ファイル作成日(和暦)/年月日(YYMMDD)]]

#page=5

>[L[表示形式:"YYYY-MM-DDT00:00:00"(時刻部分はALL0)]]

* 人間が読むことを主な目的とした日付形式

[SEE[ [[日時表示]] ]]


* 自然言語っぽい日時の指定

[SEE[ [[日時表示]] ]]

* 各部について

[SEE[ [[日時構成要素]] ]]

** 年号

[78] [[2桁西暦年号の解釈]]や[[1万年問題]]も参照。


[30] 月: 情報交換用日付形式は一般に認めていませんが、1月、2月、3月を前年の13月、14月。15月にすると[[年度]]の関係で扱いがよくなることがあります。予定管理系ソフトウェア(謎)などでは採用の検討に値するでしょう。 ([[ツェラーの公式]]なんかもこの方法を使いますね。)

[31] [[人が読む日付形式][日時表示]]では、 
[WEAK[(特に[[欧米]]で)]] [[月名]] [WEAK[(数字ではなく。)]] 
を使うのが好まれることがあります。例えば、 [[ISO 8601の日付形式]] の [SAMP[2003-01-02]] よりも [[RFC 2822の日付形式]]の [SAMP[02 Jan 2003]] の方が良いという人もいます。これは、欧米では >>1 に挙がっている解釈の多義性が大きな問題だからです。4桁年号と月の名前と日付の数字なら、解釈は明らかです。
- [32] しかしながら、人が読む部分ではなく、機械が解釈するプロトコル要素では、形式をしっかり決めてしまえば曖昧性は無いので、どうでもいいといえばどうでもいいです。 (名前と番号の変換表の容易の手間の分だけ微妙に数字方式が楽でしょう。)
- [33] また、 >>31 で人間に読ませるのが文章の途中ではなくソフトウェアの画面の一部なのであれば、[[地域化]]の時に月名を翻訳する (更に言えば、月名で表記する習慣が無い言語・地域もあるので、結局数字表記も選択可能である) 必要があります。 ([[locale]])

[76] [[紀年法]]も参照。

** 月

[90] [[機械処理]]用に限らず[[日付]]の表記においては[[月]]と[[日]]の順序問題による混乱を防ぐため、
[[月番号]]ではなく[[月名]]の表記が好ましいとされる場合があります。

[EG[
[91] 例えば [[RFC 822の日時形式]]は実際に3文字の[[英語]]の省略形の[[月名]]を使っています。
]EG]

;; [92] [[月]]も参照。

** 時

[8] ほとんどの表記法は、[[午前]]・[[午後]]の区別をせず、24時間制としています。

[9] 午前・午後を区別する場合は、真夜中と昼の0時が午前なのか午後なのか,
更に "0" 時なのか "12" 時なのかに注意する必要があります。

[12] >>9 区別しない場合においても、 "0" 時と "24" 時の扱いが問題になります。
"24:00" の存在を認めている形式もあれば、いない形式もあります。
- [16] [[夏時刻制]]を導入している地域では、同じ数字の時刻が[[標準時]]と[[夏時刻]]で2回あったり、1度もなかったり、あるいは ''24:00〜25:00 が存在''したりします。夏時刻への移行の方法や時期は地域により異なりますし、同じ地域でも年により異なることが少なくないので注意が必要です。

[17] 起き続けている間を論理''日''として、翌日の午前 [VAR[n]] 時をその日の ([VAR[n]] + 24) 時と呼ぶ人もいます。例えば翌日午前2時が26時となります。

;; [[30時間制]]を参照。


[74] [CITE@ja[Xユーザーの眼精疲労さん: 「@fumokmm これ混在してて相当苦しんだ 時間については午前午後を1と2で分けてあったり… 会社の長老に聞かにゃわからんてw」 / X]], [TIME[午前11:16 · 2023年9月4日][2023-09-04T02:16:15.000Z]], [TIME[2023-09-05T03:28:40.000Z]] <https://twitter.com/zawaji_rainfall/status/1698520318044709212>

** 秒

[4] [[秒]]は、厳密には[[閏秒]]の挿入を考慮する必要があります。
しかし多くの場合には、無視されています。

;; 詳細は[[閏秒]]、[[閏秒のない時刻系]]を参照。

** 秒未満

[10] [[秒未満]] ([[秒の小数部]]) を扱える規格や実装はほとんどありませんでしたが、
徐々に増えてきています。

** 時間帯

[96] [[時差の記述]]参照。

* 曖昧性の記述

[79] 正確な[[日時]]が不明である時、[[人間]]向けであれば「約」や「頃」や「?」や
「○日から○日」のように[[日時]]の記述の前後で補足したり、[[時間間隔]]として記述したりします。

[80] 機械向けの場合、[[分]]まで、[[日]]までといった精度の低い構文を選択的に用いたり、
始点と終点の組の[[時間間隔]]として記述したりします。

[81] 正確な[[日時]]が不明であることを記述したり、推定される範囲を記述したりできる[[日時形式]]もあります。

[FIG(short list)[ [13] [[日時]]の曖昧性の記述
- [[ISO 8601-2]]
- [[EDTF]]
- [[BDF][Bibliographic Datetime Format]]
- [[TEMPER]]
- [[Exifの日時形式]]
- [[MySQLの日時形式]]
- [CODE[-00:00]]
]FIG]

* 暦法との関係

[SEE[ [[過去の日時]]、[[将来の日時]] ]]

[SEE[ [[時差の記述]]、[[日時の暦法明記]] ]]

* 日付形式記述形式

[69] [[日時パターン]]参照。

* 局所的な時間軸における時刻の表記

[56] [[相対時刻]]参照。

* 時間の表記

[58] ある[[時刻]]からある[[時刻]]までの範囲や、特定の[[時刻]]を想定しない[[時間]]の長さを表す書式もいろいろあります。
次の各項を参照。

[FIG(short list)[
- [[時間長形式]]
- [[時刻の範囲の形式]]
]FIG]

* 休日

[62] [SEE[ 休日、祝日、祝祭日などに関しては[[休日]] ]]

* 宇宙の日時

[40] [SEE[ [[宇宙の日時]] ]]

* 日時処理の観点

[SEE[ 一般的事項は[[日時処理]] ]]

[93] [[文字列]]としての[[整列]]が[[日時]]としての[[整列]]になることを極めて重視して設計された[[日時形式]]として、
例えば[[RFC 2550の日時形式]]があります。

[94] そうした配慮がなければ、一般には[[日時]]の[[整列]]には特別な処理が必要です。

[95] [[ISO 8601の日時形式]]とその派生形式各種は、実用的な範囲内では[[文字列]]としての[[整列]]が[[日時]]としての[[整列]]となる場合が多いです。
(例えば[[1万年][1万年問題]][[以上]]の[[日時]]などでそれが崩れます。)

[FIG(quote)[
[FIGCAPTION[
[67] [CITE[日付の順番がややこしい件 | ニコニコニュース]]
([TIME[2016-01-07 18:08:31 +09:00]] 版)
<http://news.nicovideo.jp/watch/nw201545>
]FIGCAPTION]

> アメリカで働いている知人によると、「社内で共有するファイルは、必ずファイル名の先頭に日付をいれているんだけど、『月、日、年』の順番で書くから、フォルダに並んでいるファイルが古い順に並ばなくて不便」

]FIG]


* プライバシー

[25] [[日時のプライバシー]]を参照。

* メモ

- [2] ''日付の表記に関するノート'' <http://www.kanzaki.com/docs/html/dtf.html>
-- [3] 入門用にはわかりやすくて(・∀・)イイ!!です。
- [22] ''Bug 118266 - JS Date type mixed with document.cookie considered harmful'' <http://bugzilla.mozilla.org/show_bug.cgi?id=118266>
- [41] ''415063 - FTP のファイル一覧で今年のファイルが去年の日付で表示される'' <http://support.microsoft.com/default.aspx?scid=kb;ja;415063>: [[FTP]] のファイル一覧で送られてくる日付情報が完全修飾じゃないので補う時に変な計算をしてしまって年がずれるバグ。 IE がへたれなのはもちろんだけど、 FTP の歴史的機械に優しくない仕様は痛いなあと。
- [44] Referer によれば日付の足し算引き算をしたい人が一杯いるみたいだ。(すれ違いだけど。でも計算がしやすい形式、しづらい形式というのがあるという点ではやっぱり関係はあるか。) [[perl]] なら [CODE(perl)[[[Date::Calc]]]] とかが定番ですかね。

[54] [CITE[OASIS CAM V1.1 Specification]]
( ([TIME[2007-06-18 21:16:59 +09:00]] 版))
<http://docs.oasis-open.org/cam/v1.1/os/OASIS-CAM-Specification-1_1-015-060107.html>

[65] [CITE[データ連携と統合を科学するブログ: グレゴリオ暦?ユリウス暦? データベースによって異なる、日付時刻型が扱える範囲]]
([TIME[2015-12-22 03:02:21 +09:00]] 版)
<http://bitdatasci.blogspot.jp/2014/12/blog-post.html>

[FIG(quote)[
[FIGCAPTION[
[57] [CITE@en[Providing Structured Data  |  Custom Search  |  Google Developers]]
([TIME[2015-12-02 02:24:14 +09:00]] 版)
<https://developers.google.com/custom-search/docs/structured_data?csw=1#formatting-dates>
]FIGCAPTION]

> 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.

]FIG]




[68] [CITE@en[15114 – forms: new <input> type for YYYY / YYYY-MM / YYYY-MM-DD / YYYY-MM-DD hh:mm, at user's choice]]
([TIME[2016-01-08 16:28:55 +09:00]] 版)
<https://www.w3.org/Bugs/Public/show_bug.cgi?id=15114>

[66] [CITE[SAS日付関連のフォーマット,インフォーマット - CatTail Wiki*]]
([TIME[2016-01-20 22:26:22 +09:00]] 版)
<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>


[FIG(quote)[
[FIGCAPTION[
[72] [CITE@ja-jp[日付型に思う]]
([[中博俊]]著, [TIME[2016-06-26 01:28:02 +09:00]])
<http://blogs.wankuma.com/ognac/archive/2007/06/01/79054.aspx>
]FIGCAPTION]

> 月末を意味する日に99日というのはよくありますよね。 
> 2007/02/99 
> ただ月末を31日にするのには困りました。 
> 2007/02/31 

]FIG]


[FIG(quote)[
[FIGCAPTION[
[5] [CITE@en[Providing Structured Data  |  Custom Search  |  Google Developers]]
( ([TIME[2015-12-02 02:24:14 +09:00]]))
<https://developers.google.com/custom-search/docs/structured_data#formatting_dates>
]FIGCAPTION]

> 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.

]FIG]


[6] [CITE@en[Representations of local time of the day for information interchange ... - Full View | HathiTrust Digital Library | HathiTrust Digital Library]]
([TIME[2016-09-21 10:03:28 +09:00]])
<https://babel.hathitrust.org/cgi/pt?id=uiug.30112104151292;view=1up;seq=1;size=150>

[FIG(quote)[
[FIGCAPTION[
[7] [CITE[ARIB TR-B39]]
([TIME[2016-07-25 17:01:00 +09:00]])
<http://www.arib.or.jp/english/html/overview/doc/4-TR-B39v1_0-1p4.pdf#page=28>
]FIGCAPTION]

> MH-SDTT の start_time 及び送出系の時間管理はサマータイム制の実施の有無に関わらず、常
> に「UTC(世界標準時)+9 時間」を基準とする。

]FIG]


[60] [CITE@ja[過去の年月日の表記の統一 - Uyopedia]]
([TIME[2009-02-22 00:00:31 +09:00]])
<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] [CITE[モンゴル語 文法 時間の点と幅の表現:解説]]
([TIME[2016-10-18 10:45:00 +09:00]])
<http://www.coelang.tufs.ac.jp/mt/mn/gmod/contents/explanation/055.html>

[21] [CITE@ja[日付定数]]
([TIME[2017-03-10 19:00:47 +09:00]])
<http://wiki.genexus.jp/hwiki.aspx?%E6%97%A5%E4%BB%98%E5%AE%9A%E6%95%B0,>

[43] [CITE@ja[天泣記]]
([[Tanaka Akira]]著, [TIME[2013-01-22 10:38:34 +09:00]])
<http://www.a-k-r.org/d/2012-10.html>

[FIG(quote)[
[FIGCAPTION[
[26] [CITE@en[Upwork API Reference]]
([TIME[2017-03-13 18:51:45 +09:00]])
<https://developers.upwork.com/?lang=python#contracts-and-offers_create-a-milestone>
]FIGCAPTION]

> due_dateoptional, string
> Expected date of finalization. Format mm-dd-yyyy.

]FIG]


[88] [CITE@en[15114 – forms: new <input> type for YYYY / YYYY-MM / YYYY-MM-DD / YYYY-MM-DD hh:mm, at user's choice]]
([TIME[2017-07-23 13:28:22 +09:00]])
<https://www.w3.org/Bugs/Public/show_bug.cgi?id=15114>

[FIG(quote)[
[FIGCAPTION[
[18] [CITE[○福知山市公文書例]]
([TIME[2018-05-11 10:01:19 +09:00]])
<http://www.city.fukuchiyama.kyoto.jp/reiki/405902210008000000MH/405902210008000000MH/print.html>
]FIGCAPTION]

>  (ウ) 日付・時刻及び時間の書き方
>       日付・時刻及び時間の書き方は、次の例による。
>    区分 
>      日付 
>    時刻 
>    時間 
> 普通の場合 
> (元号)2年1月1日 
>   8時30分 
>    8時間 
> 省略する場合 
> (元号)2.1.1 
>   8:30 
>       
>      (注)1 会議時間などを書く場合は、「自~至」を用いないで、「・・から
>          ・・まで」又は「~」を用いる。
>         2 記帳などで単に「月日」のみを簡略化して書く場合、例えば4月1
>          日は「4.1」と書く。

]FIG]


[FIG(quote)[
[FIGCAPTION[
[19] [CITE@ja[和暦の元号変更に伴う影響について | CA Communities]]
([TIME[2018-06-14 22:46:04 +09:00]])
<https://communities.ca.com/docs/DOC-231176865-%E5%85%83%E5%8F%B7%E5%A4%89%E6%9B%B4%E3%81%AB%E4%BC%B4%E3%81%86%E5%BD%B1%E9%9F%BF%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6>
]FIGCAPTION]

> CA Easytrieve Plus 製品自体は、稼動するシステムよりシステム日付を取得、稼動しており、和暦の認識はしておりません。
> 但し、CA Easytrieve Plus の稼動パラメータの一つであるDATEADJ パラメータへの指定によって、CA Easytrieve Plus の日付フィールドであるSYSDATE フィールド内の年部分(2桁のYY部分)を調整することができますので、結果として、和暦年となるよう調整されている場合に影響が考えられます。
> ・DATEADJ パラメータに設定された値が、0(デフォルト)である場合、システム日付をそのまま使用する事となり、影響はありません。
> ・DATEADJ パラメータに設定された値が、和暦換算となるような値(例えば、DATEADJ=88、もしくはDATEADJ=1988等)である場合には、影響がありえます。 
>  
> DATEADJ パラメータに関する詳細は、以下をご覧下さい。
>  
> DATEADJ パラメータについて
> DATEADJ パラメータには、CA Easytrieve Plus の日付フィールドであるSYSDATE フィールドの年部分を調整するために使用する基準年を設定します。
> 仕組みとしては、CA Easytrieve Plus は、稼動するシステムから、システム日付を読み込み、そのシステム日付の年部分からDATEADJ パラメータに設定した値(基準年)を減算し、減算後の値を CA Easytrieve Plus のSYSDATE フィールドに移送します。
>  
> 例えば、現在のシステム日付が、2017年3月24日(2017/03/24)であった場合、DATEADJ パラメータに、仮に88(もしくは1988等)が指定されていたならば、前述の仕組みにより、SYSDATE フィールドに設定される値は、29/03/24となります。 
> (2017 – 88 = 1929。 この計算結果の下2桁である29が、SYSDATE フィールドの年部分(YY 部分)に設定されます。)
> *DATEADJ パラメータのデフォルト値は0です。

]FIG]


[FIG(quote)[
[FIGCAPTION[
[28] ([TIME[2016-03-17 17:45:08 +09:00]])
<https://www.digital.archives.go.jp/support/pdf/kaiteiban_kitanomaru33gou_P130.pdf>
]FIGCAPTION]

> 日の判別しないものはその
> 月の最後に、月日が判別しないものはその年の最後に配列した。また、収録年代が複数年
> 月にわたる文書は、そのうちの最後の年月のところに入れるようにした

]FIG]





[37] ([TIME[2015-01-13 10:11:54 +09:00]])
<http://www.moe.gov.cn/ewebeditor/uploadfile/2015/01/13/20150113091154536.pdf>

[FIG(quote)[
[FIGCAPTION[
[14] [CITE[Microsft Access バグ 全バージョン和暦ANSI Csvファイルからインポートするとき日付をH31/2/1 S50.3.4としていると読み込みを失敗する - Qiita]]
([TIME[2019-11-02 13:15:42 +09:00]])
<https://qiita.com/Q11Q/items/dd793d751fc4d67d0c61>
]FIGCAPTION]

> ExcelはS20.5.2のようなドット区切り以外は和暦として読むし、最新版ならドット区切りでも読める。

]FIG]


[FIG(quote)[
[FIGCAPTION[
[15] [CITE[Open API_Shenzhen Jimi IoT Co., Ltd.]]
([TIME[2019-08-13 11:04:36 +09:00]])
<https://www.iconcox.com/api/jimiApi.html>
]FIGCAPTION]

> The API use UTC (GMT +0) time in default: formatyyyy-MM-dd HH:mm:ss

]FIG]


[27] [CITE@ja[これ京都?いいえ、コソボです。ヨーロッパなのにどう見ても日本な景観が話題に「木造ってだけでこんなに似るのか」 - Togetter]]
([TIME[2020-02-22 16:23:39 +09:00]])
<https://togetter.com/li/1392976#c6703160>

[29] ([TIME[2020-05-14 17:15:25 +09:00]])
<https://cio.go.jp/sites/default/files/uploads/documents/1015-1_gyousei_data_model_datetime_20200514.pdf>

[34] [CITE[Wayback Machine]]
([TIME[2020-08-21 14:21:07 +09:00]])
<https://web.archive.org/web/20200411150338/https://cio.go.jp/sites/default/files/uploads/documents/1015-1_gyousei_data_model_datetime.pdf>

[35] ([TIME[2019-03-28 22:01:11 +09:00]])
<https://cio.go.jp/sites/default/files/uploads/documents/1015-1_gyousei_data_model_datetime.pdf>

[38] ([TIME[2018-05-24 19:46:21 +09:00]])
<https://cio.go.jp/sites/default/files/uploads/documents/gyouseidata_hidukejikoku.pdf>


[39] [CITE@en['''['''Android''']''' 端末の言語を変更後「プライバシーポリシーの改定」が再表示される · Issue #49 · cocoa-mhlw/cocoa · GitHub]], [TIME[2021-03-15T06:07:41.000Z]] <https://github.com/cocoa-mhlw/cocoa/issues/49>

[42] [CITE@en[各種日付がロケール依存のフォーマットで保存される · Issue #51 · cocoa-mhlw/cocoa · GitHub]], [TIME[2021-03-15T06:08:38.000Z]] <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] [CITE@ja[接触確認アプリCOCOA、地域ごとの日付フォーマットの違いで利用日数が狂う新たな不具合 | スラド オープンソース]], [TIME[2021-03-15T06:12:14.000Z]] <https://opensource.srad.jp/story/21/03/14/166238/>


[FIG(quote)[
[FIGCAPTION[
[49] [CITE@en[Messages — Mailgun API documentation]]
([TIME[2021-04-29T14:25:26.000Z]], [TIME[2021-05-17T09:10:06.835Z]])
<https://documentation.mailgun.com/en/latest/api-sending.html#sending>
]FIGCAPTION]

> String should be set to preferred delivery time in HH:mm or hh:mmaa format, where HH:mm is used for 24 hour format without AM/PM and hh:mmaa is used for 12 hour format with AM/PM. 

]FIG]


[FIG(quote)[
[FIGCAPTION[
[50] [CITE@en[User Manual — Mailgun API documentation]]
([TIME[2021-04-29T14:25:33.000Z]], [TIME[2021-05-17T09:11:25.128Z]])
<https://documentation.mailgun.com/en/latest/user_manual.html#sending-a-message-with-tzo>
]FIGCAPTION]

> Timezones are estimated based on a user’s IP address. Mailgun collects the IP address on click events, and uses a geolocation service to translate the IP address into a timezone for the user. We store that timezone in a database (hashed, of course), so that when TZO is used on a message, Mailgun will look up the timezone for that user, and schedule the message for the delivery time in that user’s local timezone.
> You can send a message using TZO via API by passing in the parameter o:time-zone-localize or via SMTP using the MIME header X-Mailgun-Time-Zone-Localize. The value (String) should be set to preferred delivery time in HH:mm or hh:mmaa format, where HH:mm is used for 24 hour format without AM/PM and hh:mmaa is used for 12 hour format with AM/PM.

]FIG]



- [77] [CITE@ja[Xユーザーのらりお・ザ・.*🈗然㊌㋞㋰㋷㋓さん: 「ソートを気にするなら自然と YYYY-MM-DD に収束するなんてのは流石に人類に夢を見すぎ。 「stackoverflow ls sort date」で検索検索ゥ! すると、 (ls 自体に -t オプションがあるのはさておき) 「May 1」とか「Apr 3」とかのソートどうやんの??? と質問しちゃってる人々が無限にいるよ🤔」 / X]], [TIME[午後4:10 · 2023年9月22日][2023-09-22T07:10:29.000Z]], [TIME[2023-09-25T04:10:36.000Z]] <https://twitter.com/lo48576/status/1705117346535530818>
-- [82] [CITE@ja[Xユーザーのarkheさん: 「ファイル名でソートする文明社会ではYYYY-MM-DD方式でコンセンサスが取れると思うんじゃが」 / X]], [TIME[午後0:47 · 2023年9月22日][2023-09-22T03:47:01.000Z]], [TIME[2023-09-25T04:10:36.000Z]] <https://twitter.com/arkhe634/status/1705066141469818904>


[83] この種の話になると必ず >>82 のようなことを言い出す[[蛮族][過剰効率主義]]がいるが、世界は広く文化は多様。
欧米風に「価値観をアップデート」することが「文明化」と呼ばれた20世紀を経てもなお、
その欧米の実情が >>77 なんだよなあ。



- [84] [CITE@ja[Xユーザーの野菜食べたいさん: 「ほぼ ISO 準拠でかつ桁が正規化された 2024-01-17 1択 2024/01/17 のスラッシュ区切りは日本と海外で一貫性がなくガバガバなので絶対あかん,あくまで日常的な利用に限る。エンジニアリング文脈では使ったらあかん」 / X]], [TIME[午後4:49 · 2023年11月2日][2023-11-02T07:49:22.000Z]], [TIME[2023-11-02T12:10:06.000Z]] <https://twitter.com/mpyw/status/1719985031807139852>
-- [85] [CITE@ja[Xユーザーのついったーは悪い文明さん: 「国によって順序変わるのは認識してたけど、 ハイフン区切りならそれが適用されない(ってことだよね?)のは認識してなかった…… (スラッシュは避けたい度の高い記号だからハイフンの方を使いがちはあるけど)」 / X]], [TIME[午後7:04 · 2023年11月2日][2023-11-02T10:04:52.000Z]], [TIME[2023-11-02T12:10:06.000Z]] <https://twitter.com/civil_destroyer/status/1720019132442439939>


[86] 
こういう謎の誤解を招く [[ISO 8601]] 信者は罪深い。