1月11日。

今年2010年は今日が成人の日ですね。
地方によっては昨日成人式の式典を行ったところもあるようですが、今日出勤中に晴れ着を着たおねーさんをみました。

最近のおねーさんは晴れ着をきててもちっともおしとやかじゃないので、あんまり嬉しくありません。

よしぞーです。

金髪だの茶髪だのカラーリングした髪の毛で着物着るなよ！
和服に対する冒涜だよそれは！

個人的意見ではありますが、せめて和装のときくらい髪の毛は黒くあってほしい。
そう思います。

さて。
2004年の今日、銀行ATMで2038年問題が発生したのをご存知でしょうか。

2000年問題（Y2K問題）は知らない人はいないでしょうが、Y2Kなど比較にならないレベルで潜伏している問題が2038年問題なんです。

これは2038年1月19日3時14分7秒を過ぎると、コンピュータが誤動作する可能性があるという問題です。

wikiによると、
- - - - - -
標準的なC言語の実装では、時刻の表現形式としてUNIX時間《1970年1月1日0時0分0秒（UTC）からの経過秒数》を使用している。これはUNIXの仕様に由来するもので、time t型という。

C言語の規格を定めた「ISO/IEC 9899:1999」では、time_t型の範囲や精度はいずれも処理系依存としているが、time_t型は、伝統的には符号つき32ビット整数（signed long int型）であり、最大値は (231 - 1) = 2,147,483,647 となる。つまり、2,147,483,647秒までしか計算できない。

このようなAPIの下で作られたアプリケーションでは、1970年1月1日0時0分0秒から2,147,483,647秒を経過した、2038年1月19日3時14分7秒を越えると、この値がオーバーフローし、負と扱われるため、誤作動する可能性が高い。

さらに、この仕様は他の多くのプログラミング言語でも採用されているため、それらの言語で作られたアプリケーションも同様に誤作動する可能性が高い。

ただし、この期日以前でもプログラムで内部的にこの秒数を超えた時刻データを扱おうとすれば同様のエラーが発生するため、2004年1月11日にはすでにATMの誤作動といったトラブルが発生した（プログラム中に現在時刻を2倍する式があったため、2,147,483,647秒の半分以上経過した時点で誤動作が発生した）。

他にも顕在化していないトラブルが今後表面化するという可能性はあり得る。
- - - - -

つまり、誤解を恐れずに要約すると、C言語というプログラミング言語で作成されたアプリケーションでは、時刻表示の最大数が制限されており、その制限2,147,483,647秒…つまり2038年1月19日3時14分7秒を超えると誤作動を起こしてしまう、ということです。

Y2Kよりも深刻である、という理由は…

Y2kの場合はアプリレベルでの問題修正が可能であったため対応が比較的容易でしたが、今回の問題は現在普及しているC言語そのものに実装されている問題であることです。

しかも2038年1月19日3時14分7秒などというしごく中途半端な時間に、世界同時に問題が発生するために混乱が大きくなるだろう、といわれています。

同じくwikiより
- - - - -
対策としては、time_t型を符号つき64ビット整数型（一般にはlong long int型）にするという方法がある。符号つき64ビット整数型の場合、上限は9,223,372,036,854,775,807（263 - 1）である。これを秒数に用いるとおよそ西暦3000億年[3]まで使用できるので、当分の間は問題が生じない。最近のオペレーティングシステムや処理系では、time_t型は符号つき64ビット整数型で表されるようになってきている。
- - - - -

という対策があるようですが、C言語処理体系で構築されたシステムすべてを一挙に更新する、というおそらくコスト面での問題もあり、かなり難航しそうです。

関連する問題では過去に

2001年9月9日問題（2001年9月9日にtime_t型の値が999,999,999秒から1,000,000,000秒と桁が増える）
があり、将来的には
NTPやMicrosoft Windowsなど、1900年1月1日からの積算秒数で時間を表現するシステムもあり、符号なし32ビットの値が2036年2月6日にオーバーフローすることによって問題が発生する（→2036年問題）

というのもあります。

世の中イロイロ大変です。

ま、とりあえず鏡開きでもして（1月11日は鏡開き）、餅でも食べて。

専門家にでも任せましょうw