2038年問題【year 2038 problem】

概要

2038年問題（year 2038 problem）とは、西暦2038年のある瞬間を境に一部のコンピュータシステムが誤作動する可能性がある問題。古い設計のシステムが採用している日付と時刻の標準データ形式が定義上の上限値を超えてしまうために起きる。

古いUNIX系OSやC言語では、時刻を協定世界時（UTC）1970年1月1日午前0時からの経過秒数（いわゆるUNIX時間）で管理している。この値のデータ型（time_t型）はもともと32ビットの符号付き整数で実装されていたため、上限値である21億4748万3647秒を超える未来の日付・時刻は表現することができない。

経過秒数がこの上限を超えるのは（うるう秒を考慮しなければ）協定世界時の2038年1月19日午前3時14分8秒（日本時間では同日の午後12時14分8秒）であり、この形式で時刻を管理しているシステムはそれまでに対策を施さなければこの時点以降正常に動作しなくなる。また、これ以前でも将来の日付・時刻としてこの上限値を超える未来を指定しようとすれば不具合が生じる可能性がある。

対策

time_t型をより大きな値を扱えるデータ型に宣言しなおせばこの問題を回避できるが、単に宣言部分を書き換えるだけでなく、プログラム中の処理で日付・時刻データが32ビット符号付き整数でなくなると矛盾や不具合が生じる箇所がないか確認し、適宜修正する必要がある。

近年ではtime_t型を64ビット符号付き整数とするソフトウェアが増えており、西暦3000億年程度まで問題なく表すことができる。64ビット長の整数型が使えないシステムでは、一時しのぎの対策として32ビット符号なし整数型で置き換える場合もあり、2106年まで問題の顕在化を先送りすることができる。

2000年問題の教訓と比較

過去に似た問題として、年号を西暦の下二桁で記録しているシステムが2000年元日以降に誤作動するとされた「西暦2000年問題」があった。このときは事前の周知や対処が進んだこともあり社会的な混乱を引き起こすほどの大きな問題は生じなかったが、古い仕様のソフトウェアが社会のいたるところで想定を超えて長期間使われ続けている実態は衝撃を持って受け止められた。

2038年問題はまだ「その時」まで長い時間があるため、今回も適切に対処されるとする楽観論が多く聞かれるが、2000年問題のような個々のアプリケーションソフトの問題ではなくオペレーティングシステム（OS）やプログラミング言語処理系の基幹部分の仕様についての問題であるため、古い設計のまま見過ごされて問題が顕在化するシステムも相当数現れるのではないかとの見方もある。

名称	問題の日付・時刻	要因	主な対象
2000年問題	2000年1月1日～	西暦の下2桁で表した年データが十進数2桁の上限を超える	メインフレーム / COBOLプログラム等
昭和100年問題	2025年1月1日～	昭和に換算した年データが十進数2桁の上限を超える	メインフレーム / COBOLプログラム等
2036年問題	2036年2月6日6:28:15(UTC)～	1900年1月1日午前0時からの経過秒数が32ビット符号なし整数の上限を超える	NTPで時刻合わせしているシステム等
2038年問題	2038年1月19日3:14:08(UTC)～	1970年1月1日午前0時からの経過秒数が32ビット符号付き整数の上限を超える	UNIX系システム等