ids/0/45.txt

#?SuikaWiki/0.9 default-name="1970年1月1日"

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

人が書いて人が解釈していた頃は、当然混乱はあったにしろ、
文脈によりある程度使い分け・識別していました。
しかし機械が日付を扱うようになると、それに伴い表現方法は
(技術的制約などで) 更に増加し、混乱は決定的なものとなりました。
- [45] [WEAK[2004-01-21 17:29:15 +00:00]] ''1970年1月1日'': test

[46]
aaa
([[aa]] [bb] [WEAK[2004-07-29 01:02:42 +00:00]])

[54]
Not bad man! Look what i founf hier!!!!!
<a href= http://bed-bath-and-beyond-ivan.blogspot.com/ >bed bath and beyound</a>  [url= http://bed-bath-and-beyond-ivan.blogspot.com/ ]bed bath and beyound[/url]   http://bed-bath-and-beyond-ivan.blogspot.com/ 
http://bed-bath-and-beyond-ivan.blogspot.com/
([[Prohor!]] [openbfor@rtydg.com])


[[#comment]]


* 電子メイルの日付形式

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


* ISO 8601 の日付形式

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


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

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


* 言語仕様・ライブラリの日付形式


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


** Visual Basic の Date 型

[[Microsoft]] 社の言語環境である [[VisualBasic]]
で日付や時刻を扱う型である [[Date型]]の実体は[[浮動小数点型]]で、整数部で日付,
小数部で時刻を表します。
[[#comment]]


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

- [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時となります。
[[#comment]]


** 秒

[4] [[秒]]は、厳密には[[閏秒]]の挿入を考慮する必要があります。
しかし計算機やネットワークの分野ではそこまでの正確性が必要とはあまりなりませんから、閏秒を無視した規格や実装がかなり多いです。

[6] 日付の表記という面では、閏秒の削除はまず問題にはなりません。
(59秒が無くなるだけだから。) 閏秒の挿入は "60"
という普通とりえない値が必要になりますから、問題になります。

[5] 最近の規格, 例えば [[ISO 8601の日付形式]]は閏秒を記述出来ます。

[7] 古い規格や実装では閏秒が2秒分挿入されて "61"
秒もありうるとしているものがありますが、実際にそうした例はありませんし、この説は間違いであることが後に分かりました。
ですから、新しい規格や実装は "61" 秒を考慮する必要はありません。
[[#comment]]


** 秒未満

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


** 時間帯

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

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

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

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

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


* 過去の日付

- [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/>
([[名無しさん]])

[[#comment]]


* 将来の日付

[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]] に戻ってくるのがいい気がします。まあ実際にはそんなこと考えてもいられないでしょうし、考える必要もあまりないでしょうけど。
[[#comment]]


* メモ

- [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]]]] とかが定番ですかね。
1	#?SuikaWiki/0.9 default-name="1970年1月1日"
2
3	[1] 日付を文字(数字)列で表現する方法には、古来様々な
4	方法が採られてきました。しかしその試みはそれぞれ
5	独立したものであったため、多くの場合互換性がありません。
6	例えば、 01/02/03 は、地域により2001年2月3日,
7	2003年1月2日, 2003年2月1日のように複数の解釈があり得ます。
8
9	人が書いて人が解釈していた頃は、当然混乱はあったにしろ、
10	文脈によりある程度使い分け・識別していました。
11	しかし機械が日付を扱うようになると、それに伴い表現方法は
12	(技術的制約などで) 更に増加し、混乱は決定的なものとなりました。
13	- [45] [WEAK[2004-01-21 17:29:15 +00:00]] ''1970年1月1日'': test
14
15	[46]
16	aaa
17	([[aa]] [bb] [WEAK[2004-07-29 01:02:42 +00:00]])
18
19	[54]
20	Not bad man! Look what i founf hier!!!!!
21	<a href= http://bed-bath-and-beyond-ivan.blogspot.com/ >bed bath and beyound</a> [url= http://bed-bath-and-beyond-ivan.blogspot.com/ ]bed bath and beyound[/url] http://bed-bath-and-beyond-ivan.blogspot.com/
22	http://bed-bath-and-beyond-ivan.blogspot.com/
23	([[Prohor!]] [openbfor@rtydg.com])
24
25
26
27
28
29	[[#comment]]
30
31
32	* 電子メイルの日付形式
33
34	[[電子メイル]]の[[頭]]の部分に記述する日付の形式です。
35	現在では頭は基本的に機械が処理する部分との認識・実装が
36	一般的ですが、かつては人が読み書きするのが当然でしたから、
37	斜線を使う方式での解釈の多義性が問題視されたのです。
38	- [23] 電子メイル・電子ニュースの日付形式は長く混乱していて、どの仕様にも合致しない形式がかなり多く使われていました。その一端の''とっても簡単な''調査結果: ''EMail Msg <199312160130.TAA09527@austin.BSDI.COM>'' <http://ksi.cpsc.ucalgary.ca/archives/WWW-TALK/www-talk-1993q4.messages/869.html>
39	- [24] >>23 簡単な調査でこれだけ見つかるんですから、実際にはこの2,3倍の変種があった可能性があります。
40	[[#comment]]
41
42
43	** [[RFC 561の日付形式]]
44
45	- 24 JUL 1973 1527-PDT
46	- 7/27/1973 1527-PDT
47
48
49	** [[RFC 724の日付形式]]
50
51	- 26 August 1976 1429-EDT
52	- Wednesday, 8/31/76 1251-Z
53
54	RFC 561 の形式の上位互換のようです。
55	斜線を使う形式は地域により解釈が異なり得るので非推奨とされてます。
56
57
58	** [[RFC 733の日付形式]]
59
60	- 26 Aug 76 1429 EDT
61
62	RFC 724 の英月名形式とほぼ同じ物です。
63
64
65	** [[RFC 822の日付形式]]
66
67	- 26 Aug 76 14:29:01 EDT
68
69	RFC 733 の形式と似ていますが、時間(hour)と分・秒の
70	区切りの ":" が必須となりました。
71
72	なぜか年号が2桁でなければならないように退化しています。
73
74	電子ニュース・メッセージでの[[RFC 1036の日付形式]]にそのまま
75	採用されました。
76
77
78	** RFC 1123 の日付形式
79
80	- Fri, 15 Mar 2002 16:53 +0900
81
82	RFC 822 の形式の小改訂で、4桁の西暦年号が認められ、
83	推奨されました。また、[[時間帯]]は数値表現が推奨されています。
84
85	[[MIME]] や [[HTTPの日付形式]]でもほぼそのまま採用されています。
86	([[RFC 3339の日付形式]]登場以前の) Internet
87	標準の日付形式と考えられていました。
88
89
90	** [[RFC 2822の日付形式]] (822形式の subset)
91
92	[[RFC 822の日付形式]] (RFC 1123 で改訂) と実質的に同じです。
93	但し新しいメッセイジに使われる形式として、より厳格な書式が
94	定義されています。
95
96
97	** [[RFC 1505]] の日付形式
98
99	[[RFC 822の日付形式]]の秒の後に、1秒に満たない秒数(ってへんな
100	いいかただけど。) が6桁分まで書ける様に拡張したものです。
101	RFC 1505 が普及しなかったので、この形式も普及しませんでした。
102
103
104	* 電子ニュースの日付形式
105
106	[[USENET]] では元々 [[ARPANET]] の[[電子メイル]]とは
107	違った形式を使っていましたが、[[電子ニュース]]のメッセージの形式自体
108	が RFC 822 とほとんど同じ物になったので、日付形式もそうなりました。
109
110	[[RFC 850の日付形式]]→[[RFC 1036の日付形式]] ([[RFC 822の日付形式]]と同じ)
111	→[[usefor-articleのDate:欄]]
112
113	ただし、電子ニュースの記事では RFC 822 とは異なり、途中での
114	FWS や [[comment]] の自由な挿入は許されていません。
115	当初からほぼ RFC 2822 の obs でない構文相当でした。
116
117
118	* [[HTTPの日付形式]]
119
120	[[HTTP/1.0]] 以降は RFC 822
121	と同じ様なメッセージ形式を使っていますから、
122	[[RFC 822の日付形式]] (をやや限定したもの)
123	を標準としていますが、標準化が遅れている間に自分の好きな形式を送る実装が多くなりすぎたために、
124	[[RFC 850の日付形式]] (旧) や [[asctime形式]]も理解出来なければならず、
125	更にそれ以外の形式も頑張って解釈できるようにすることになっています。
126
127
128	* ISO 8601 の日付形式
129
130	[[ISO 8601の日付形式]]は、その名の通り [[ISO 8601]]
131	で規定された形式ですが、 [[ISO 8601]]
132	そのものは具体的な形式を定めず、様々な日付要素を定義して、これを組み合わせて柔軟に実際の形式を確定できるようになっています。
133
134
135	** [[RFC 3339の日付形式]]
136
137	[[RFC 3339]] は、 Internet の新しい標準時刻表現形式を規定しています。
138	これは [[ISO 8601]] のプロファイルであり、 W3C [[HTML4]]
139	などで採用されている日付形式とほぼ同じものです。
140
141
142	* 言語仕様・ライブラリの日付形式
143
144
145	** [[asctime形式]]
146
147	[[ANSI]] [[C]] の asctime() の日付形式です。
148	[[C]] や [[perl]] などでは非常に手軽に扱うことが出来るので、よく使われます。このため[[HTTPの日付形式]]にも含まれています。
149	[[#comment]]
150
151
152	** Un*x time
153
154	The epoch (1970年1月1日0時0分0秒 ([[GMT]])) からの経過秒数を使うのが
155	[[Un*x時間]]形式です。
156	[[Un*x]] で動作するプログラムを中心に内部処理形式・保存形式として非常に良く使われています。
157
158	[11] 閏秒が扱えないという問題がありますが、これまであまり意識されてきませんでした。
159	[[#comment]]
160
161
162	** Visual Basic の Date 型
163
164	[[Microsoft]] 社の言語環境である [[VisualBasic]]
165	で日付や時刻を扱う型である [[Date型]]の実体は[[浮動小数点型]]で、整数部で日付,
166	小数部で時刻を表します。
167	[[#comment]]
168
169
170	* 人間が読むことを主目的とした日付形式
171
172	- [29] [CODE[22/Jul/2002:11:57:36 +0900]]
173	[[#comment]]
174
175
176	** 2ch の日付形式
177
178	- [13] (旧) [SAMP[2001/02/09(金) 22:49]]
179	-- [[閉鎖騒動]]以前に使われていた形式。
180	- [14] (新) [SAMP[02/12/18 22:56]]
181
182	[48]
183	最近100分の1秒単位で入るようになりました。
184	([[名無しさん]] [sage] [WEAK[2005-12-31 12:40:02 +00:00]])
185
186	[49]
187	>>48 ([[VIP]]では。)
188	([[名無しさん]] [sage])
189
190	[50]
191	2006年3月31日の次は3月32日になりました。
192	([[名無しさん]] [WEAK[2006-03-31 16:13:50 +00:00]])
193
194	[51]
195	>>50 その翌日は4月2日でしたが、[[VIP]]など一部の板では3月33日になりましたw
196	([[名無しさん]] [WEAK[2006-04-01 16:15:27 +00:00]])
197
198	[52]
199	[CODE(example)[佐賀暦2006年,2006/10/21(佐賀) 03:11:20.28]] @ [[VIP]]
200	([[佐賀県]]記念)
201
202	([[名無しさん]] [WEAK[2006-10-21 01:19:45 +00:00]])
203
204	[53]
205	[[VIP]] では[Q[2007/02/13(火)]]の次は[Q[2007/02/15(水)]]になりました。
206
207	([[名無しさん]] [WEAK[2007-02-14 13:26:34 +00:00]])
208
209	[[#comment]]
210
211
212	** /. の日付形式
213
214	- [15] [SAMP[Monday December 02, @10:38AM]]
215	[[#comment]]
216
217
218	* 各部について
219
220
221	** 年号
222
223	- [[2桁西暦年号の解釈]]
224	- [30] 月: 情報交換用日付形式は一般に認めていませんが、1月、2月、3月を前年の13月、14月。15月にすると[[年度]]の関係で扱いがよくなることがあります。予定管理系ソフトウェア(謎)などでは採用の検討に値するでしょう。 ([[ツェラーの公式]]なんかもこの方法を使いますね。)
225	- [31] 人が読む日付形式では、 (特に[[欧米]]で) 月名 (数字ではなく。) を使うのが好まれることがあります。例えば、 [[ISO 8601の日付形式]] の [SAMP[2003-01-02]] よりも [[RFC 2822の日付形式]]の [SAMP[02 Jan 2003]] の方が良いという人もいます。これは、欧米では >>1 に挙がっている解釈の多義性が大きな問題だからです。4桁年号と月の名前と日付の数字なら、解釈は明らかです。
226	- [32] しかしながら、人が読む部分ではなく、機械が解釈するプロトコル要素では、形式をしっかり決めてしまえば曖昧性は無いので、どうでもいいといえばどうでもいいです。 (名前と番号の変換表の容易の手間の分だけ微妙に数字方式が楽でしょう。)
227	- [33] また、 >>31 で人間に読ませるのが文章の途中ではなくソフトウェアの画面の一部なのであれば、[[地域化]]の時に月名を翻訳する (更に言えば、月名で表記する習慣が無い言語・地域もあるので、結局数字表記も選択可能である) 必要があります。 ([[locale]])
228	[[#comment]]
229
230
231	** 時
232
233	[8] ほとんどの表記法は、[[午前]]・[[午後]]の区別をせず、24時間制としています。
234
235	[9] 午前・午後を区別する場合は、真夜中と昼の0時が午前なのか午後なのか,
236	更に "0" 時なのか "12" 時なのかに注意する必要があります。
237
238	[12] >>9 区別しない場合においても、 "0" 時と "24" 時の扱いが問題になります。
239	"24:00" の存在を認めている形式もあれば、いない形式もあります。
240	- [16] [[夏時刻制]]を導入している地域では、同じ数字の時刻が[[標準時]]と[[夏時刻]]で2回あったり、1度もなかったり、あるいは ''24:00〜25:00 が存在''したりします。夏時刻への移行の方法や時期は地域により異なりますし、同じ地域でも年により異なることが少なくないので注意が必要です。
241	- [17] 夏時間とは関係ありませんが、起き続けている間を論理''日''として、翌日の午前 [VAR[n]] 時をその日の ([VAR[n]] + 24) 時と呼ぶ人もいます。例えば翌日午前2時が26時となります。
242	[[#comment]]
243
244
245	** 秒
246
247	[4] [[秒]]は、厳密には[[閏秒]]の挿入を考慮する必要があります。
248	しかし計算機やネットワークの分野ではそこまでの正確性が必要とはあまりなりませんから、閏秒を無視した規格や実装がかなり多いです。
249
250	[6] 日付の表記という面では、閏秒の削除はまず問題にはなりません。
251	(59秒が無くなるだけだから。) 閏秒の挿入は "60"
252	という普通とりえない値が必要になりますから、問題になります。
253
254	[5] 最近の規格, 例えば [[ISO 8601の日付形式]]は閏秒を記述出来ます。
255
256	[7] 古い規格や実装では閏秒が2秒分挿入されて "61"
257	秒もありうるとしているものがありますが、実際にそうした例はありませんし、この説は間違いであることが後に分かりました。
258	ですから、新しい規格や実装は "61" 秒を考慮する必要はありません。
259	[[#comment]]
260
261
262	** 秒未満
263
264	[10] 秒未満を扱える規格や実装はほとんどありませんでしたが、最近増えてきています。
265	例えば [[RFC 3339の日付形式]]は Internet
266	標準として秒未満の記述を可能にしています。
267	また [[GNU]] [[diff]] の出力には秒未満の欄があります。
268	- [26] 但し書式として秒未満が扱えたとしても、それが正しいかどうかは別問題です。 (もちろん、秒以上の正確性の問題もありますが、秒未満はその細かさ故により精度に疑問があります。) 書式としての秒未満を扱えても、実際には内部で捨てている実装も少なくないでしょう。
269	- [27] 秒未満を書式又は内部的にも扱える実装であっても、 [[RFC 3339]] のように無限の精度を許したものをどう扱っているかは激しく実装依存と思われます。
270	- [28] それに、 [[RFC 3339 の日付形式]] (のようなもの) で秒未満が無い形式を、固定長として扱っている実装だって少なくは無い ([[XSLT]] スタイル・シートとか特に。) ですから、下手に秒未満を入れるとおかしくなる可能性も。
271	[[#comment]]
272
273
274	** 時間帯
275
276	[[RFC 2822]], [[son-of-RFC1036]], [[usefor]] では数値形式を推奨。
277	[[HTTP]]では文字列「GMT」固定。
278
279	非標準の時間帯文字列を使う実装がかなりあった。今は少ないと思う。
280	各地で観測されている[[時間帯を表す文字列]]の一覧参照。
281
282	数値形式に、注釈で文字列を添える (eg. +0900 (JST)) のが、 [[RFC 2822]]の
283	[[Received:領域]]における推奨。だけど、そういうのを
284	[[Date:欄]]でやると意味の分からない足し算・引き算を
285	やる訳の分からん実装 ([[Windoze]] 95 の M$ Exchange らしい。)
286	があるという罠。
287
288	「-0000」は時間帯不明を表すという慣習があって、[[RFC 2822の日付形式]]
289	で明文化された。 UTC との時差が整数分にならない時もこれを
290	使うといいらしい。(ほんとか? ; この話はどの仕様書にも
291	載ってない。; ていうか整数分にならない地域ってどこよ?)
292
293	[[RFC 3339]] にこの話も載ってます。時差が整数分にならないのは、
294	過去にあったけど現在はないようです。 [[RFC 3339]] は、そうした
295	時間帯は他の適当な(表現可能な)時間帯に直すように指示しています。
296	("-00:00" にしろとまでは言ってない。)
297	- [25] 過去の[[リベリア]]では -00:44:30 を使っていたらしいです。
298	[[#comment]]
299
300
301	* 過去の日付
302
303	- [34] 過去の日付の取扱いは茨の道です。
304	- [35] 多くの処理系が採用している [[Un*x時間]]は、 [[TheEpoch]] ([CODE[1970-01-01T00:00:00+00:00]]; [CODE[0]]) 以前が扱えません。 (一部、負の値を使って扱えるように拡張している実装もありますが。)
305	- [36] そして、 >>35 の問題が解決したとすると、次にましますは[[暦]]の問題です。[[グレゴリオ暦]]改暦以前は[[ユリウス暦]]として扱わなければなりません。
306	- [37] >>26 しかも改暦は国・地域により異なります。
307	- [38] >>36-37 [[日本]]の場合はグレゴリオの前は[[天保暦]] ([[太陰太陽暦]]) だったりします。
308	- [39] で、それ以前となると、国・地域ごとに暦はばらばら、暦の運用も不規則 (理論上の閏とかを運用してなかったり。)、時代が遡ると詳細不明だったり、ということで、過去の日付の処理の実装はいかに暦データベースを上手く実装するか、ということになりそうです。
309	- [42] 実際に扱えるようになったら、その環境で入力されたデータは改暦を考慮したか否かとかでぐちゃぐちゃになりそう。実際に巷で流れてる、例えば歴史的事項の日付がどういう暦での日であるのかは明記されないことが普通だし。
310
311	[47]
312	[CITE[DCMI Date Working Group]] <http://www.dublincore.org/groups/date/>
313	([[名無しさん]])
314
315	[[#comment]]
316
317
318	* 将来の日付
319
320	[18] 将来の日付の扱いも面倒です。将来行われうる暦法の変更を我々は知り得ないからです。
321	おそらく最も現実的な解は、
322	- 年月日のように簡単に仕組みが変わりそうにないものは、とりあえず現在の法則が適用されると仮定し、出来るだけ長くその方法で使えるようにする。 (実質的には、年の数が大きくなっても扱えるように、ということ。)
323	- 閏秒や時間帯 (特に夏時刻) のように頻繁に変わり得るものは、プログラムの外部の設定ファイルを参照するなどして簡単に修正可能にしておく。
324
325	ことくらいでしょうか。
326
327	また、情報記録用の形式に通し時 (Un*xtime やユリウス日など)
328	ではなく [[ISO 8601]] のような人間可読形式を採用するのも良い考えかもしれません。
329	2003年1月1日の (365*100+閏日の数) 日後が2103年1月1日になる保証はありませんからね。
330
331	- [19] [[2000年問題]]: 既に過去になってしまった、''将来の日付''の問題。
332	- [20] [[10000年問題]]: まだ''遠い将来''である、将来の日付の問題。
333	- [21] [[Un*x時間]]: 32ビット整数桁溢れ問題 (いわゆる2038年問題)
334	- [43] 将来閏日が増えたり減ったり、あるいは時の為政者が2月30日を作るとか言い出したらどうでしょう? 理論上は閏日の調整はグレゴリオ暦で数万年は狂わないそうですけど、後者はあり得るかも。なんにせよ、将来のことは分からない。だから例えば、 [CODE[10000-02-31]] みたいなデータは、もし処理系に余裕があるなら、内部形式に変換して外部形式に再変換した時にも [CODE[10000-02-31]] に戻ってくるのがいい気がします。まあ実際にはそんなこと考えてもいられないでしょうし、考える必要もあまりないでしょうけど。
335	[[#comment]]
336
337
338	* メモ
339
340	- [2] ''日付の表記に関するノート'' <http://www.kanzaki.com/docs/html/dtf.html>
341	-- [3] 入門用にはわかりやすくて(・∀・)イイ!!です。
342	- [22] ''Bug 118266 - JS Date type mixed with document.cookie considered harmful'' <http://bugzilla.mozilla.org/show_bug.cgi?id=118266>
343	- [40] 地球外の日付: [[RFC 1607]] には月時間とか火星時間が出てきますが、近未来にはこれが現実の問題となります。地球外の時刻がどう表現されるかはわかりませんが、計算機表現もどう扱うか大きな問題になりそうです。
344	- [41] ''415063 - FTP のファイル一覧で今年のファイルが去年の日付で表示される'' <http://support.microsoft.com/default.aspx?scid=kb;ja;415063>: [[FTP]] のファイル一覧で送られてくる日付情報が完全修飾じゃないので補う時に変な計算をしてしまって年がずれるバグ。 IE がへたれなのはもちろんだけど、 FTP の歴史的機械に優しくない仕様は痛いなあと。
345	- [44] Referer によれば日付の足し算引き算をしたい人が一杯いるみたいだ。(すれ違いだけど。でも計算がしやすい形式、しづらい形式というのがあるという点ではやっぱり関係はあるか。) [[perl]] なら [CODE(perl)[[[Date::Calc]]]] とかが定番ですかね。