はじめに
皆さんは「西暦2038年問題」をご存じでしょうか？
ITに携わっている方の中には「西暦2038年問題」をご存じの方も多いかと思います。
今回は、「西暦2038年問題」について説明します。
「西暦2038年問題」とは？
「西暦2038年問題」とは、西暦2038年1月19日3時14分7秒を過ぎると、コンピューターのOS（UNIX系OS）が誤動作する可能性があり、それに伴い、OS上で動作しているアプリケーションやシステムも誤動作する可能性があるという問題です。
特に、社会基盤を司るシステム（電気、水道、ガス、通信、交通、流通など）や、医療などを司るシステムについては、「西暦2038年問題」によりシステムダウンした場合など、社会的な影響も大きいとされています。
ただし（ここから重要）、社会基盤を司るシステムや医療などを司るシステムが、「西暦2038年問題」を引き起こすような古いOSのコンピューターを、西暦2038年までに使用することは考えづらいため、実際は大きな問題は起きないと考えます。
「西暦2038年問題」が起きる理由
「西暦2038年問題」が起きる理由は、古いOS（UNIX系OS）では、日付や時刻を西暦1970年1月1日 AM00:00からの経過秒数で管理しています。
つまり、OS内では西暦1970年1月1日 AM00:00から現在も1秒ずつ加算されて管理されています。
OSの内部では、西暦1970年1月1日 AM00:00からの経過秒数を、32ビットの符号付き整数で経過時間を管理しており、32ビットの符号付き整数で管理できる21億4748万3647秒経過すると上限値に達してしまい、本来の日付や時刻を表現出来なくなるという理由です。
「西暦2038年問題」を回避するには
「西暦2038年問題」を回避するには、まずはコンピューターおよびOS（UNIX系OS）が32ビットかどうかを確認する必要があります。
もし、32ビットの符号付き整数で経過時間を管理している下記のような本当に古いOSの場合は、OSのバージョンを上げるなどの対応が必要です。
・Linux ext2
・Linux ext3
・Linux ReiserFS
・etc
最近のOSでの日付や時刻の管理は、64ビットの符号付き整数で経過時間を管理しているため、「西暦2038年問題」は起きません。
「最後に」
これまでもIT業界では、2000年問題やうるう秒問題など、様々な日付、時刻に関する問題が取り上げられてきましたが、実際には大きな問題は起きていないというのが現状です。
先にも述べましたが、「西暦2038年問題」を引き起こすような古いOSのコンピューターを、西暦2038年までに使用することは考えづらいため、実際には大きな問題は起きないと筆者は考えています。
［PS］
ちなみにですが、2000年問題の時は筆者も必至に西暦2桁の4桁対応を実施しました．．．
