タブクリアです、こんにちは。

猛暑続きで遠出する気力も出ないため、たまにはIT企業らしくIT系の話題を…。

先月１日、うるう秒対応が話題となりました。
BREASTOでも、社内外のシステムにおいて、問題がないかの調査を行うなど、少しではありますが、影響はありました。

この手の問題でインパクトの大きかったものは、今となっては懐かしさすら感じる2000年問題ですが、将来、影響が大きそうなものが「2038年問題」です。（NTPによる時刻合わせを行っているシステムでは、「2036年問題」も影響が大きいと思われますが、　詳しい説明は割愛します。ご興味のある方は調べてみてください）

これについては、e-Wordsの「2038年問題」に簡潔な説明があるので、そのまま引用します。（以下、http://e-words.jpより引用）

———-
「2038年問題とは、一部のOSやプログラミング言語処理系の仕様により、西暦2038年以降の日付や時刻を正しく扱えない問題。また、それが原因でコンピュータが一斉に誤作動を起こし社会に混乱を招く可能性があるという問題。

古いUNIXやC言語では時刻を1970年1月1日午前0時からの経過秒数で管理している。この値は32ビットの符号付き整数（signed long int型）で実装されていることが多いため、上限値である21億4748万3647秒を超えると正しく時刻を表現できなくなる。経過秒数がこの上限を超えるのは世界標準時で2038年1月19日午前3時14分8秒（日本時間午後12時14分8秒）であり、この形式で時刻を管理しているシステムはそれまでに対策を施さなければこの時点以降正常に動作しなくなる。

最近のOSや言語処理系では対策として時刻の管理に64ビットの符号付き整数を利用しており、これを1970年1月1日午前0時からの経過秒数として使えば西暦3000億年程度までは同種の問題は起きない。

似たような問題としては、西暦を下2桁で管理していたコンピュータが西暦2000年を迎え不具合を生じるとされた『西暦2000年問題』があったが、このときは大きな社会的混乱は生じなかった。

このときはアプリケーションソフトの仕様とデータ形式の問題だったため個々の問題としては修正は比較的容易だったが、2038年問題は最も普及しているプログラミング言語の仕様に関わる問題だけに対処は難しいのではないかとも言われる。」
———-
（以上引用）

2000年問題の時同様、いろいろな問題が懸念されていますが、中には、「核兵器が誤発射される」などどいった物騒なものも…。

この問題は、実は十年以上前の2004年1月11日に、一部の銀行ATMで誤作動が起きるなど、コンピューター内部の実装によっては、すでに起きてしまっているものもあります。

まだ先とは言え、プログラムの改修レベルで済むのであれば、可能な限り改修を、
それが出来ないのであれば、64ビットマシンにシステムそのものをリプレースするなどの処置が必要になってくるかもしれませんね。

上記の記事にもありましたが、アプリケーションの仕様を変更すればよいわけではなく、ミドルウェアやOSレベルでの影響があるので、思うように対応できないパターンもありそうな気がします。

そう考えると、IT業界全体としては、2000年問題の時以上に、大きなビジネスになりそうな気がしますね。

私は2038年には定年退職しているはずなのですが、対応で人手が足りなくなった場合、ひょっとしたら駆り出されているかも…。

後輩の皆さんは、頑張ってくださいね。