2038年問題とは

f:id:ryoutaku_jo:20190812131433p:plain

【結論】

・「2038年問題」とは、2038年1月19日3時14分7秒(UTCを過ぎると、コンピュータが誤作動する可能性があるとされている問題

・コンピュータの時刻表現で広く使用されている「UNIX時間」は、1970年1月1日0時0分0秒からの経過秒数で時間を計測している

・経過秒数は、伝統的な実装では符号つき32ビットで計測しているが、その最大値が「2,147,483,647(2の31乗 − 1)」であることが原因

【目次】

【本題】

2038年問題について

2038年問題」とは、UNIX系のOSを用いたコンピュータが、協定世界時(略称はUTC)の2038年1月19日3時14分7秒(日本時間では午後0時14分7秒)を過ぎると、コンピューターが正しく時刻を認識できなくなり、誤作動が発生する可能性があるとされている問題です。

1999年から2000年に変わる際にも、コンピュータが誤動作を起こす可能性がある2000年問題が大きく話題になりましたが、それに近い内容です。

2000年問題」は、それほど大きな影響は出ませんでしたが、「2038年問題」はどうなのでしょうか?

原因

UNIXの環境などで広く用いられている「UNIX時間」は、1970年1月1日0時0分0秒からの経過秒数で時間を計測しています。

この経過秒数は、伝統的な実装方法では32ビットの符号付き整数で計算しています。

32ビットの符号付き整数は −2,147,483,648 から 2,147,483,647 までの数しか格納できません。

その為 「2,147,483,647」を過ぎると、値がオーバーフローして、32ビットの符号付き整数の一番最初である「−2,147,483,648」になってしまいます。

これが基で、正しく時刻が扱えなくなり、様々な処理に誤動作を引き起こしてしまう可能性があります。

f:id:ryoutaku_jo:20190812161758g:plain

対策

有効な対策は、符号つき64ビット整数で計測にするという方法です。

符号つき64ビット整数型の場合、上限は9,223,372,036,854,775,807 (2の63乗 − 1) です。

年換算すると、西暦3000億年まで使用できるので、事実上問題が発生することはありません。

2000年問題との違い

同じ様な問題で「2000年問題」というものが以前大きな話題になりました。

2000年問題」は、西暦を扱う際に下2桁だけを表示して、上位2桁を省略していることが原因で生じました。

この違いにより、「2038年問題」は以下の点で「2000年問題」より深刻だと言われています。

  • C言語処理系やOSのAPIといったシステムの深いレイヤに問題が潜んでいるので、修正作業が複雑になる

  • 構造を理解するには、ある程度の専門知識を必要とするので、経営者・政治家などエンジニア以外の理解と関心を得にくい可能性がある

  • 中途半端な時刻に問題発生のタイミングが訪れるので、もしトラブルが発生しても対応できる人的リソースの確保が困難になる可能性がある

2000年問題」は話題の大きさに反して、比較的大きなトラブルになる事はありませんでしたので、「2038年問題」も杞憂に終わるかもしれません。

しかしエンジニアなら、理解はしておくべきテーマでしょうね。

参考情報

2038年問題とは何? Weblio辞書

2038年問題 - Wikipedia

《今日の学習進捗(3年以内に10000時間に向けて)》

今日はダイビングデーにつき勉強なし

学習開始からの期間 :246日
今日までの合計時間:2339h
一日あたりの平均学習時間:9.6h
今日までに到達すべき目標時間:2247h
目標との解離:92h
「10,000時間」まで、

残り・・・「7661時間!」