技術情報

技術情報

開発者コラム

図研エルミックのエンジニアが開発にまつわるコラムを書いています。


 

2011年 news76号

2011/04/01

「2000年問題再び?」

LW事業部 開発1課 K.M

このたびの東日本大震災により被害を受けられました皆様にお見舞いを申し上げます。 一日も早い復旧を心よりお祈りしています。

さて、私が最近関わった仕事でUNIX時間を算出する処理を使用したものがありました。 UNIX時間とは1970年1月1日0時0分0秒からの経過秒数のことで多くのC言語の実装で使用されています。 それを調査・検討している過程で興味深い問題を見つけました。 皆様は2038年問題という言葉をご存知でしょうか。

これはUNIX時間を使う時の型:time_t型が符号付き32ビット整数として定義されていることにより発生する問題です。 符号付き32ビット整数の場合、扱える値は -2147483648~2147483647となるため、この環境で表現できるUNIX時間は1970年1月1日0時0分0秒から2147483647秒後までとなります。 これを超えた場合は桁あふれが発生するためUNIX時間が -2147483648 と判断されてしまいます。

この桁あふれが発生する時間が2038年1月19日3時14分7秒ということで2038年問題と呼ばれています。 今となってはもう11年前の話となりますが、社会的にも大きな話題となった2000年問題のような話です。

time_t型を64ビット又は符号なし32ビットに定義することで回避は可能だとは思います。 しかし2000年問題の時とは違い、こちらは処理系の実装の問題ということで対応する場合は2000年問題の時より綿密な調査と検証が必要になることが予想されます。

現在ではtime_t型を64ビットで実装したものも登場していて、2038年まであと27年あるので対策する時間はまだ沢山ありますし、それまでに殆どのシステムは入れ替わっているかもしれません。

しかし2000年問題の時もそうでしたが、危機が目の前に迫らないとこうしたことになかなか目が向かないのと、現在でもPC98ベースのシステムなどレガシーな物が動作していることを考えるとこの問題が全て解決し、忘れ去られている可能性は低いと考えます。

27年後、自分が対処することになるか分かりませんが同じような問題を発生させることのないよう、意識して取り組みたいと思います。

最後までご覧いただきまして、ありがとうございました。

 
(c) 2011 ZUKEN ELMIC,INC. All rights reserved.

バックナンバー

↑ ページTOPへ