2017年12月10日

改めて2038年問題を考える…すでに2004年に問題が発生していたとは知らなかった

昨日、TL上で2038年問題に関する話題が上がっていて、そういえば、2038年問題って、実際に発生するXデーがいつなのかよく分かっていなかったことに気づきました。

2000年問題なら、2000/1/1 0:00:00 という、一般人でも分かりやすい日付時刻に発生する事象でしたが、2038年問題はそんなに分かりやすい日付時刻ではないはず。C言語を扱うプログラマ以外の一般の人にとっても、わかりにくい事象となるでしょう。

2038年問題とは、C/C++のtime_t型が1970年1月1日0時0分0秒からの積算秒数と定義されており、その最大値の一般的な実装が2,147,483,648となっていることから、その最大値を超えたときに不具合が発生するというものです。

というわけで、Xデーは、世界協定時で2038年1月19日03時14分7秒(UTC)となります。
日本時間だと、2038年1月19日12時14分7秒(JST)になるので、もしトラブルが発生するとしたら真っ昼間です。大混乱になるかもしれません。

2000年問題の時と同様に、全世界のSEが血眼になって、問題が発生しないよう努力するはずなので、きっと何も起きないはず…であることを祈りたいです。

この問題をWikipediaで調べていて知ったのですが、2004年には既に、2038年問題を原因とするトラブルが発生していたんだそうでビックリです。


ちなみに、INASOFTで公開しているソフトウェアでも、問題となるC/C++言語のtime_t型を使っている箇所があります。
各プログラムに搭載されている「CCPU(環境情報の表示)」で、DHCPの有効期限を表示する機能がありますが、取得のためにGetAdaptersInfo() APIを用いており、そこで使用される構造体IP_ADAPTER_INFOの中に、time_tがあります。

たしか、64bit環境ではtime_tは64bitになっていたはずなので、2038年問題のXデーは西暦3000年まで延長されるはず。
32bit環境として動作するプログラムについては、2038年以降は、DHCPの有効期限が正しく表示されない不具合に見舞われるということになりそうです。

この他に、libpngとzlibのコードの中でtime_tが使われているのを見かけました。
もしかしたら、これが何らかの問題に繋がる可能性もあるかもしれません。ただ、INASOFTで公開しているソフトウェアでlibpngを利用していたプログラムは、現在、サポート終了としてしまっているので、問題が起きても特に対応はしない予定です。

まぁ、20年後にINASOFTがまだ続いているとも限りませんけどね。


【C/C++の最新記事】
【紹介する】
 
posted by ayacy at 00:24 | Comment(0) | TrackBack(0) | C/C++
この記事へのコメント
コメントを書く
お名前: [必須入力]

メールアドレス:

ホームページアドレス:

コメント: [必須入力]

認証コード: [必須入力]


※画像の中の文字を半角で入力してください。
※ブログオーナーが承認したコメントのみ表示されます。
この記事へのトラックバックURL
http://blog.sakura.ne.jp/tb/181803566
※ブログオーナーが承認したトラックバックのみ表示されます。
※言及リンクのないトラックバックは受信されません。

この記事へのトラックバック