【結論】
・「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」になってしまいます。
これが基で、正しく時刻が扱えなくなり、様々な処理に誤動作を引き起こしてしまう可能性があります。
対策
有効な対策は、符号つき64ビット整数で計測にするという方法です。
符号つき64ビット整数型の場合、上限は9,223,372,036,854,775,807 (2の63乗 − 1) です。
年換算すると、西暦3000億年まで使用できるので、事実上問題が発生することはありません。
2000年問題との違い
同じ様な問題で「2000年問題」というものが以前大きな話題になりました。
「2000年問題」は、西暦を扱う際に下2桁だけを表示して、上位2桁を省略していることが原因で生じました。
この違いにより、「2038年問題」は以下の点で「2000年問題」より深刻だと言われています。
構造を理解するには、ある程度の専門知識を必要とするので、経営者・政治家などエンジニア以外の理解と関心を得にくい可能性がある
中途半端な時刻に問題発生のタイミングが訪れるので、もしトラブルが発生しても対応できる人的リソースの確保が困難になる可能性がある
「2000年問題」は話題の大きさに反して、比較的大きなトラブルになる事はありませんでしたので、「2038年問題」も杞憂に終わるかもしれません。
しかしエンジニアなら、理解はしておくべきテーマでしょうね。
参考情報
《今日の学習進捗（3年以内に10000時間に向けて）》
今日はダイビングデーにつき勉強なし
学習開始からの期間 ：246日
今日までの合計時間：2339h
一日あたりの平均学習時間：9.6h
今日までに到達すべき目標時間：2247h
目標との解離：92h
「10,000時間」まで、
残り・・・「7661時間！」