192.txt

[1] 日付を文字(数字)列で表現する方法には、古来様々な
方法が採られてきました。しかしその試みはそれぞれ
独立したものであったため、多くの場合互換性がありません。
例えば、 01/02/03 は、地域により2001年2月3日,
2003年1月2日, 2003年2月1日のように複数の解釈があり得ます。

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

* 内部表現と外部表現

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

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

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

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

* 電子メイルの日付形式

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


* [[HTTPの日付形式]]

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

* [[Webの日時形式]]

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

* [[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形式]]

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


** [[Un*x time]]

The epoch (1970年1月1日0時0分0秒 ([[GMT]])) からの経過秒数を使うのが
[[Un*x時間]]形式です。
[[Un*x]] で動作するプログラムを中心に内部処理形式・保存形式として非常に良く使われています。

[11] 閏秒が扱えないという問題がありますが、これまであまり意識されてきませんでした。
[[#comment]]

** [[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]]]] など[[日付]]を[[文字列]]に変換する[[メソッド]]が定義されています。

** [[Visual Basic]] の [[Date]] 型

[[Microsoft]] 社の言語環境である [[Visual Basic]]
で日付や時刻を扱う型である [CODE(VB)@en[[[Date]]]] 型の実体は[[浮動小数点型]]で、整数部で日付,
小数部で時刻を表します。

** その他

[74] 
[FIG(short list)[
- [[JavaScriptの日付形式]]
- [[MySQLの日付形式]]
- [[Exifの日時形式]]
- [[GPS時]]
]FIG]

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

- [29] [CODE[22/Jul/2002:11:57:36 +0900]]
[[#comment]]


** 2ch の日付形式

- [13] (旧) [SAMP[2001/02/09(金) 22:49]]
-- [[閉鎖騒動]]以前に使われていた形式。
- [14] (新) [SAMP[02/12/18 22:56]]

[48]
最近100分の1秒単位で入るようになりました。
([[名無しさん]] [sage] [WEAK[2005-12-31 12:40:02 +00:00]])

[49]
>>48 ([[VIP]]では。)
([[名無しさん]] [sage])

[50]
2006年3月31日の次は3月32日になりました。
([[名無しさん]] [WEAK[2006-03-31 16:13:50 +00:00]])

[51]
>>50 その翌日は4月2日でしたが、[[VIP]]など一部の板では3月33日になりましたw
([[名無しさん]] [WEAK[2006-04-01 16:15:27 +00:00]])

[52]
[CODE(example)[佐賀暦2006年,2006/10/21(佐賀) 03:11:20.28]] @ [[VIP]]
([[佐賀県]]記念)

([[名無しさん]] [WEAK[2006-10-21 01:19:45 +00:00]])

[53]
[[VIP]] では[Q[2007/02/13(火)]]の次は[Q[2007/02/15(水)]]になりました。

([[名無しさん]] [WEAK[2007-02-14 13:26:34 +00:00]])

[[#comment]]


** /. の日付形式

- [15] [SAMP[Monday December 02, @10:38AM]]
[[#comment]]


* 各部について


** 年号

- [[2桁西暦年号の解釈]]
- [30] 月: 情報交換用日付形式は一般に認めていませんが、1月、2月、3月を前年の13月、14月。15月にすると[[年度]]の関係で扱いがよくなることがあります。予定管理系ソフトウェア(謎)などでは採用の検討に値するでしょう。 ([[ツェラーの公式]]なんかもこの方法を使いますね。)
- [31] 人が読む日付形式では、 (特に[[欧米]]で) 月名 (数字ではなく。) を使うのが好まれることがあります。例えば、 [[ISO 8601の日付形式]] の [SAMP[2003-01-02]] よりも [[RFC 2822の日付形式]]の [SAMP[02 Jan 2003]] の方が良いという人もいます。これは、欧米では >>1 に挙がっている解釈の多義性が大きな問題だからです。4桁年号と月の名前と日付の数字なら、解釈は明らかです。
- [32] しかしながら、人が読む部分ではなく、機械が解釈するプロトコル要素では、形式をしっかり決めてしまえば曖昧性は無いので、どうでもいいといえばどうでもいいです。 (名前と番号の変換表の容易の手間の分だけ微妙に数字方式が楽でしょう。)
- [33] また、 >>31 で人間に読ませるのが文章の途中ではなくソフトウェアの画面の一部なのであれば、[[地域化]]の時に月名を翻訳する (更に言えば、月名で表記する習慣が無い言語・地域もあるので、結局数字表記も選択可能である) 必要があります。 ([[locale]])
[[#comment]]


** 時

[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時間制]]を参照。

** 秒

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

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

** 秒未満

[10] 秒未満 ([[秒の小数部) を扱える規格や実装はほとんどありませんでしたが、最近増えてきています。
例えば [[RFC 3339の日付形式]]は Internet 
標準として秒未満の記述を可能にしています。
また [[GNU]] [[diff]] の出力には秒未満の欄があります。
[[HTMLの日付形式]]でも[[秒の小数部]]を記述できます。

- [26] 但し書式として秒未満が扱えたとしても、それが正しいかどうかは別問題です。 (もちろん、秒以上の正確性の問題もありますが、秒未満はその細かさ故により精度に疑問があります。) 書式としての秒未満を扱えても、実際には内部で捨てている実装も少なくないでしょう。
- [27] 秒未満を書式又は内部的にも扱える実装であっても、 [[RFC 3339]] のように無限の精度を許したものをどう扱っているかは激しく実装依存と思われます。
- [28] それに、 [[RFC 3339 の日付形式]] (のようなもの) で秒未満が無い形式を、固定長として扱っている実装だって少なくは無い ([[XSLT]] スタイル・シートとか特に。) ですから、下手に秒未満を入れるとおかしくなる可能性も。
[[#comment]]


** 時間帯

[[RFC 2822]], [[son-of-RFC 1036]], [[usefor]] では数値形式を推奨。
[[HTTP]]では文字列「GMT」固定。

非標準の時間帯文字列を使う実装がかなりあった。今は少ないと思う。
各地で観測されている[[時間帯を表す文字列]]の一覧参照。

数値形式に、注釈で文字列を添える (eg. +0900 (JST)) のが、 [[RFC 2822]]の
[[[CODE(822)@en[Received]]:]] 欄における推奨。だけど、そういうのを
[[[CODE(822)@en[Date]]:]] 欄でやると意味の分からない足し算・引き算を
やる訳の分からん実装 ([[Windows 95]] の [[Microsoft Exchange]] らしい。)
があるという罠。

「-0000」は時間帯不明を表すという慣習があって、[[RFC 2822の日付形式]]
で明文化された。 UTC との時差が整数分にならない時もこれを
使うといいらしい。(ほんとか? ; この話はどの仕様書にも
載ってない。; ていうか整数分にならない地域ってどこよ?)

[[RFC 3339]] にこの話も載ってます。時差が整数分にならないのは、
過去にあったけど現在はないようです。 [[RFC 3339]] は、そうした
時間帯は他の適当な(表現可能な)時間帯に直すように指示しています。
("-00:00" にしろとまでは言ってない。)
- [25] 過去の[[リベリア]]では -00:44:30 を使っていたらしいです。

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

[56] [[媒体]]内の経過時間によって[[媒体]]中の時間軸的位置を特定したり、
ある時刻からの[[時間]]の長さによって次の操作や[[キャッシュ]]の有効期間を指定したりと、
局所的かつ相対的な時間軸における時刻を表記する場面も多々あり、そのための書式もいろいろあります。

- [55] [[WebVTTの時刻形式]]

* 相対的な日時の表記

[70] [[ambtime]]

* 時間の表記

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

- [[時間形式]]

* 過去の日付

- [34] 過去の日付の取扱いは茨の道です。
- [35] 多くの処理系が採用している [[Un*x時間]]は、 [[TheEpoch]] ([CODE[1970-01-01T00:00:00+00:00]]; [CODE[0]]) 以前が扱えません。 (一部、負の値を使って扱えるように拡張している実装もありますが。)
- [36] そして、 >>35 の問題が解決したとすると、次にましますは[[暦]]の問題です。[[グレゴリオ暦]]改暦以前は[[ユリウス暦]]として扱わなければなりません。
- [37] >>26 しかも改暦は国・地域により異なります。
- [38] >>36-37 [[日本]]の場合はグレゴリオの前は[[天保暦]] ([[太陰太陽暦]]) だったりします。
- [39] で、それ以前となると、国・地域ごとに暦はばらばら、暦の運用も不規則 (理論上の閏とかを運用してなかったり。)、時代が遡ると詳細不明だったり、ということで、過去の日付の処理の実装はいかに暦データベースを上手く実装するか、ということになりそうです。
- [42] 実際に扱えるようになったら、その環境で入力されたデータは改暦を考慮したか否かとかでぐちゃぐちゃになりそう。実際に巷で流れてる、例えば歴史的事項の日付がどういう暦での日であるのかは明記されないことが普通だし。

[47]
[CITE[DCMI Date Working Group]] <http://www.dublincore.org/groups/date/>

[59] 計算機処理では、[[グレゴリオ暦]]を過去に延長した[[先発グレゴリオ暦]]を用いることが多いです。

* 将来の日付

[18] 将来の日付の扱いも面倒です。将来行われうる暦法の変更を我々は知り得ないからです。
おそらく最も現実的な解は、
- 年月日のように簡単に仕組みが変わりそうにないものは、とりあえず現在の法則が適用されると仮定し、出来るだけ長くその方法で使えるようにする。 (実質的には、年の数が大きくなっても扱えるように、ということ。)
- 閏秒や時間帯 (特に夏時刻) のように頻繁に変わり得るものは、プログラムの外部の設定ファイルを参照するなどして簡単に修正可能にしておく。

ことくらいでしょうか。

また、情報記録用の形式に通し時 (Un*xtime やユリウス日など)
ではなく [[ISO 8601]] のような人間可読形式を採用するのも良い考えかもしれません。
2003年1月1日の (365*100+閏日の数) 日後が2103年1月1日になる保証はありませんからね。

- [19] [[2000年問題]]: 既に過去になってしまった、''将来の日付''の問題。
- [20] [[10000年問題]]: まだ''遠い将来''である、将来の日付の問題。
- [21] [[Un*x時間]]: 32ビット整数桁溢れ問題 (いわゆる2038年問題)
- [43] 将来閏日が増えたり減ったり、あるいは時の為政者が2月30日を作るとか言い出したらどうでしょう? 理論上は閏日の調整はグレゴリオ暦で数万年は狂わないそうですけど、後者はあり得るかも。なんにせよ、将来のことは分からない。だから例えば、 [CODE[10000-02-31]] みたいなデータは、もし処理系に余裕があるなら、内部形式に変換して外部形式に再変換した時にも [CODE[10000-02-31]] に戻ってくるのがいい気がします。まあ実際にはそんなこと考えてもいられないでしょうし、考える必要もあまりないでしょうけど。

* 日時形式と時間帯/時差

@@
[73] XXX

* 日付形式記述形式

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

* 休日

[62] [[休日]]、[[祝日]]、[[祝祭日]]などに関しては、[[休日]]の項を参照してください。

* メモ

- [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>
- [40] 地球外の日付: [[RFC 1607]] には月時間とか火星時間が出てきますが、近未来にはこれが現実の問題となります。地球外の時刻がどう表現されるかはわかりませんが、計算機表現もどう扱うか大きな問題になりそうです。
- [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]


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

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

]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[
[71] [CITE@ja[OpenVMS - Wikipedia]]
( ([TIME[2016-05-12 12:23:07 +09:00]]))
<https://ja.wikipedia.org/wiki/OpenVMS>
]FIGCAPTION]

> VMSは、エポックからの経過ナノ秒を64ビットで保持することで時刻を管理している。OpenVMSのエポックは、修正ユリウス日が0となる1858年11月17日の真夜中である。

]FIG]


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