子供、いらない

はりょ。少子化問題とは関係ありません。
カウンタが345678やその付近の方はベースノートに書き込んでね。

2038年問題とUNIX時間

2005-11-27 01:55:11 | junk.test.body

コンピュータにおける2038年問題をご存知でしょうか?
ちょうど猫さんと鰹くんがコンピュータの日付や時刻に関してお話しているようなので、ちょっと会話を覗いてみましょう。


kazwo_27.gif 鰹「最近ね、2038年01月19日の日付のスパムメールがよく届くんだけど、どうしてそんな未来のメールが届くの?」
neko.gif 猫「それはね、メールの送信日付(Date:フィールド)をメールの送信者が付けることになっているのを悪用して、スパムメールが常に最新のメールとして上位に表示されるように、故意に未来の値にしているんだね」
kazwo_27.gif 鰹「でもなんで、2038年01月19日なんてキリの悪い日付なの?2100年とか3000年の方がキリが良いじゃない」

あれ、鰹くんのいっていることって何処かおかしいですね。
鰹くんと猫さんがお話を続けているようなので、もう少し見てみましょうか。

neko.gif 猫「そうだね。動物の世界では2038年よりも3000年の方がキリが良いかも知れないけど、コンピュータの世界ではそうでもないんだよ」
kazwo_27.gif 鰹「それって、どういう意味?」
neko.gif 猫「多くのコンピュータアプリケーションでは、『1970年01月01日からの経過時間』で日付と時刻を表現しているんだよ。そして、2038年01月19日03時14分07秒(UTC)/12時14分07秒(JST)の1秒後は、経過時間が負の値になって正しく日付を処理できないこともあるんだ」
kazwo_27.gif 鰹「え?それってまるで2000年問題みたいじゃん」
neko.gif 猫「そうだね。2038年01月19日03時14分08秒(UTC)/12時14分08秒(JST)は、2000年01月01日00時00分00秒と同様に、コンピュータの世界ではとってもキリの良い数字といえるかもね」

UNIXというOSやC言語で書かれたアプリケーションでは、「紀元日時(1970年01月01日00時00分00秒)からの経過時間を示す秒数」で日付・時刻を表現しているのです。
また、UNIX/C言語登場以降の他の処理系(OSやコンピュータ言語)でも、同様または類似した方式を採用しているものも多くあるようです。

そして、経過秒数に32ビット符号付整数を用いると、2038年01月19日03時14分07秒(UTC)が2,147,483,647(0x7FFFFFFF)秒経過した状態であり、その1秒後は経過秒数が-2,147,483,648(0x80000000)という負の値になります。
# -2,147,483,648は2の補数表現を用いる処理系の値であり、それ以外の場合はこの限りではありません

勿論、経過時間にミリ秒単位の64ビット符号付整数を用いる処理系や、数値1桁に文字1文字と同じ領域を割り当てる処理系もありますので、全てのシステムやアプリケーションでこの問題が発生する訳ではありません。

例えばHP-UX(32ビット)では、1901年12月13日(金) 20:45:52(UTC)から2038年01月19日(火) 03:14:07(UTC)まで扱えるそうで、経過秒数が32ビット符号付整数の最小値(-2,147,483,648)であれば、1901年12月14日(土) 05:45:52(JST)になるようです。
しかし同じHP-UXでもHP-UX(64ビット)では、1901年12月13日(金) 20:45:52(UTC)から9999年12月31日(金) 23:59:59(UTC)まで扱えるそうです。これは、下限は互換性のためか32ビット版と同じ値に揃え、上限は適当な値として10000年未満に止めているからなのでしょう。

kazwo_27.gif 鰹「そうか。日付・時刻を2038年01月19日00時00分位にしておけば、多くのアプリケーションで正しく扱える範囲の未来だから、多くのメールソフトで常に最新メールとして扱われるんだね」
neko.gif 猫「そうだね。経過秒数として32ビット符号付整数が使われているメーラが多いなら、一番安全な未来日時ってことになるね」

gooメールとYahoo!メールでは、2038年01月19日03時14分07秒(UTC)や2038年01月19日12時14分07秒(JST)のメールは、「38/01/19 12:14」とか「2038 1/19(火) 12:14」とかいうように表示され、日時順に並べると最新メールの位置に表示されました。

しかし、gooメールでは、2038年01月19日03時14分07秒(UTC)よりも未来のメールは、「70/01/01 09:00」という紀元日時の表示になり、最も古いメールになりました。
また、Yahoo!メールでは、2038年01月19日03時14分08秒(UTC)のメールが「1901 12/14(土) 05:45」、2039年01月19日03時14分08秒(UTC)のメールが「1902 12/14(日) 05:45」などと経過秒数を負の値として計算した日付に変換され、手元のメールの中では一番古い位置に表示されていました。

あっそういえば、猫さんと鰹くんはまだお話を続けているようです。
# 忘れていました(をぃ)

kazwo_27.gif 鰹「ってことは、スパムメールの発信者は変なところに気が利くのね」
neko.gif 猫「をぃをぃ。そういうのは、気が利くじゃなくて狡賢いっていうの。自分の利益だけを考えて、相手のことは全く考慮していないんだから!」
kazwo_27.gif 鰹「そっか、ごめんなさい。でも、2038年には2000年問題と同じような事態になるのかな」
neko.gif 猫「そうだね。経過秒数にもっと桁数の多い整数を使えばいいんだけど、全てのシステムが2038年問題に対応するまでには時間が掛かるかも知れない。できれば、2000年の苦い経験を活かして早めに対応してもらって、あれほど混乱しないで欲しいね

めでたしめでたし


↑B2038年からのメール - ぴよこ日和 2005年11月24日23:37
過去からのメール。 - オオカミの遠吠え通信 2006年05月06日12:04
2038年問題 - Wikipedia
2の補数 - Wikipedia
ctime(3C) - HP-UX 11i バージョン 2 リファレンス Vol. 6



最新の画像もっと見る

2 コメント

コメント日が  古い順  |   新しい順
ほーなるほど (きたむー)
2005-11-27 19:00:42
詳しい事は理解してないんですが、

そういう理由でわざわざ2038年に設定したメールが届いているんですね。

なるほど。

確かに1901年のヤツもたまに来てます。

しかも私もメアドじゃないのに来てるんですよね。

もう意味わかんなくて、来る度に消してるんでいいんですけど・・・。
返信する
自分のアドレスがないことも (かつを)
2005-11-28 02:29:44
よくありますね。

こんな下らない事に労力を割くくらいなら、違うところに力を入れて欲しいところです>スパマー
返信する

コメントを投稿