2038年問題

デジタル大辞泉

にせんさんじゅうはちねん‐もんだい〔ニセンサンジフハチネン‐〕【二〇三八年問題】

読み方：にせんさんじゅうはちねんもんだい

《Year 2038 problem》協定世界時で、西暦2038年1月19日午前3時14分7秒を過ぎると、コンピューターが誤作動を起こすことによって生じる各種システムの不具合や社会的混乱。UNIX(ユニックス)が管理する日付時刻のオーバーフローに起因する。→二〇〇〇年問題 →二〇三六年問題

IT用語辞典バイナリ

2038年問題

読み方：にせんさんじゅうはちねんもんだい
別名：西暦2038年問題，コンピュータの2038年問題，コンピュータの西暦2038年問題
【英】the year 2038 problem

2038年問題とは、UNIX環境で運用されているシステムにおいて、西暦2038年1月に時間計測の値がオーバーフローを起こして誤作動する可能性があるという問題のことである。

UNIXの環境は1970年1月1日0時0分0秒を時刻計算の起点としており、32ビットの符号付き整数で経過秒数を計測することによって時刻を計算している。こうした環境では累計で2の31乗秒、およそ21億秒を超えると、数値が正しく扱えなくなって誤作動を起こす可能性がある。1970年1月1日から累計21億秒後を迎えるのが、西暦2038年1月19日にであるとされている。

2004年に、KDDIが国内通話サービスにおいて通話料金が一部過剰に請求されていたことが判明したが、その原因は2038年問題によるものであると発表されている。問題が発生したシステムは0.5秒単位で時刻を計測するシステムで、2004年1月は1970年から2038年までの期間のちょうど半分にあたっていた。

企業活動のほかの用語一覧

コンピュータシステム：

1Uサーバー  2000年問題  2036年問題  2038年問題  5250  TSS  TCO

>>コンピュータシステムカテゴリの他の用語

ウィキペディア

2038年問題

出典: フリー百科事典『ウィキペディア（Wikipedia）』 (2025/08/07 09:03 UTC 版)

2038年問題（にせんさんじゅうはちねんもんだい）は、協定世界時（UTC）2038年1月19日3時14分7秒（日本標準時の場合、1月19日12時14分7秒）を過ぎると、コンピュータが誤動作する可能性があるとされる年問題。

経緯

上から、2進・十進・問題のある時刻・正しい時刻。（GIFアニメ）3時14分7秒を超えたところで負の値となり、時刻に狂いが生じる恐れがある。

コンピュータおよびコンピュータプログラムにおける時刻の表現として「UNIX時間」（協定世界時における1970年1月1日0時0分0秒からの経過秒数）を採用しているシステムがある。

UNIXおよびUNIX派生のオペレーティングシステム（OS）における基幹ソフトウェア部品の多くはC言語で書かれているが、前述の経過秒数を表現する型は、現在の標準では、「time_t型」である。C言語の標準である「ISO/IEC 9899:1999」では、time_t型の範囲や精度はいずれも実装定義としている。UNIXの標準（POSIX）には「shall be integer or real-floating types.」とのみ記述があり、ビット幅および値の範囲については何らの定めも無い。

伝統的な実装ではtime_tをintまたはlongのtypedefによる型エイリアス（別名）とし、その型は符号付き32ビット整数型であった。このため最大値は (2³¹ − 1) = 2,147,483,647 となり、取り扱えるのは2,147,483,647秒（≒ 68年）までに限られていた。これを前提として作成されたプログラムは、協定世界時における1970年1月1日0時0分0秒（日本標準時では1970年1月1日9時0分0秒）から2,147,483,647秒を経過した、2038年1月19日3時14分7秒（日本標準時では2038年1月19日12時14分7秒、閏秒は考慮していない）を過ぎると、この値がオーバーフローし、もし時刻を正しく扱えていることを前提としたコードがあれば、誤動作する。

ある実装におけるtime_tの型を変更することだけであれば、プログラム中のたった1箇所（typedef）を書き換えるだけであるが、実際の運用では、アプリケーションプログラムにおける時刻の扱い全てが正しくある必要がある。また、すでにあるデータ構造中で32ビット固定長として割り当てられていれば、問題が発生する。たとえば、Linuxのファイルシステムであるext2・ext3・ReiserFSのタイムスタンプは同日付までしか対応していない。

この期日以前でもプログラムで内部的にこの制限を超えた時刻データを扱おうとすれば同様のエラーが発生するため、たとえばちょうど半分を経過した2004年1月11日にはすでにATMの誤動作といったトラブルが発生した。この事例ではプログラム中のある時刻と別の時刻の中間の時刻を求めるような処理で、相加平均を単純に求める $(t_{1}+t_{2})/2$ のような式を利用していたものとみられる。他にも顕在化していないトラブルが今後表面化するという可能性はあり得る。

2000年問題はアプリケーションレベルでの修正が可能であったが、この問題は現在普及しているC言語処理系やOSのAPIといったシステムの深い層に潜む問題であるため、2000年問題より深刻であるという指摘もある。

対策

対策としては、time_t型を符号付き64ビット整数型（一般にはlong long int型）にするという方法がある。符号付き64ビット整数型の場合、上限は9,223,372,036,854,775,807（2⁶³ − 1）である。これを年数に変換するとおよそ西暦3000億年まで使用できるので、事実上問題が発生することは遠く後になる。64ビット版のオペレーティングシステムや処理系では、time_t型は符号付き64ビット整数型で表されるようになってきている。UNIXベースのOSでは、64ビット版でtime_tも併せて64ビット化されることが多い。

何らかの事情によりtime_tを64ビット化できない環境に対しては、time_tを符号無し32ビット整数型（一般的にはunsigned long int型）にするという回避策が使われることもある。この場合、上限は4,294,967,295（2³² − 1）となり、2106年2月7日6時28分15秒（閏秒を考慮しない場合）まで表現可能になる。従って2038年問題は回避できるが、結局2106年には問題が発生するため、あくまで64ビット化が困難な環境に限って適用すべき方法とされる。

macOS（Mac OS X 10.0）ではNSDateクラスにて協定世界時の2001年1月1日0時ちょうどをエポックタイムとして刷新し、また経過時間の内部表現として倍精度浮動小数点数を用いるようになったため、これらを使用している限り、2038年については問題を回避できる。なお、macOS Mojaveは32ビットアプリケーションを動作させることのできる最後のバージョンとなり、macOS Catalinaでは起動することができなくなった。

32ビット版のMicrosoft Windows（Win32）では内部時刻の表現に64ビット化されたFILETIME構造体を使っており、time_tを使っているわけではない。そのため、Windows OS側に関しては、旧OSに関する一部のケースを除き、32ビット版であっても2038年問題は発生しない。ただし、Microsoft C/C++（MS-C）および古いバージョンのMicrosoft Visual C++（MSVC）においては、time_tは32ビットのlong intを使って定義されていたため、これらの古い処理系のC/C++ランタイムライブラリ（CRT）を利用して構築されたアプリケーションソフトウェアやDLLなどは、2038年問題を抱えていることになる。x64アーキテクチャの64ビット版Windows OS上ではWOW64サブシステムによりx86アーキテクチャ向けに構築された32ビットアプリケーションも動作させることができるが、古い32ビットアプリケーションにおける2038年問題は、たとえWindows OSを64ビット版に入れ替えたとしても回避することはできない。Microsoft Visual C++ 2005以降では、既定でtime_tは__time64_tと等しく、32ビットアプリケーションであってもtime_tは64ビット化されるため、古いアプリケーションを新しい処理系およびランタイムで構築し直せば2038年問題を回避できる。

関連した問題

• 時刻aと時刻bのちょうど中間の時刻を求める時、それぞれのUnixタイムをTaとTbとして、（Ta+Tb）/ 2 と計算すると、2038年問題の半分以降が経過していればTa+Tbの計算でオーバーフローし、誤った結果となる。これは1,073,741,824 秒目で、2004年1月10日13時37分4秒以降がこの場合に相当する。2004年1月10日あるいは11日に、この事例と推察される報告があった。 この問題を回避するためには、計算方法を工夫する必要がある。例えば、時刻の中間を求める際に、オーバーフローを避けるために次のような方法が考えられる:
  1. 時刻の差を計算する: まず、時刻bから時刻aを引いて、その差を求める。
  2. 差の半分を求める: 求めた差を2で割る。
  3. 時刻aに加える: 最後に、時刻aに差の半分を加えることで、中間の時刻を求める。 この方法を数式で表すと、次のようになる： 中間時刻＝Ta +（Tb−Ta）/ 2

類似する年問題

• 2001年9月9日問題は、2001年9月9日にtime_t型の値が9億秒から10億秒と桁が増えることに伴う問題。time_t型の値を文字列（辞書順）でソートしていたことで、「9億 > 10億」と判断され、項目の新旧が正しく判断されず、新しく作られた項目が表示されない、古いものとみなされ削除されるなどの問題が発生した。
• NTPなど、1900年1月1日からの積算秒数で時間を表現するシステムもあり、符号なし32ビットの値が2036年2月7日6時28分15秒 (UTC) を超えるとオーバーフローすることによって問題が発生する（→2036年問題）。SNTPv4を定めたRFC 4330には、最上位ビットが0の場合は時刻が2036年から2104年の間であるとみなして、2036年2月7日6時28分16秒（UTC）を起点として計算することで2036年問題を回避する方法が書かれている。
• 2038年4月23日問題 - ユリウス通日を内部日付表現に用いる物のうち、基準日（グレゴリオ暦1858年11月17日正午）からの修正ユリウス日（MJD）を使用し、かつ16ビットで処理しているシステムでは、日数が16ビットからあふれるために問題が起こる。

関連項目

• UNIX時間
• ジョン・タイター
• 2000年問題

外部リンク

• 2038年問題へのカウントダウン（日本語）

ウィキペディア小見出し辞書

2038年問題

出典: フリー百科事典『ウィキペディア（Wikipedia）』 (2022/02/13 01:55 UTC 版)

「UNIX」の記事における「2038年問題」の解説

詳細は「2038年問題」を参照 Unixでは、システム時刻の値を1970年1月1日の午前0時0分0秒からの秒数で表しており、これをUNIX時間と呼ぶ。この値のデータ型は time_t で、歴史的に「符号つき long」と定義されている。32ビットのシステムでは、2038年1月19日にこの値が1個の0に31個の1が続く最大値 (0x7FFFFFFF) となり、1秒後には1個の1と31個の0が続く値 (0x80000000) となる。するとシステム時刻は、実装によって（符号ビットを無視するか否かによって）1901年または1970年にリセットされる。 1970年より前の時刻をUNIX時間で表すことは滅多にないため、time_t を符号なし32ビット整数と定義し直すという対策が考えられる。しかし、それでは単に問題を2106年2月7日に遅延させるだけであり、時刻の差を計算するソフトウェアでバグを生じる可能性がある。 この問題に対処しているバージョンもある。例えば、SolarisやLinuxの64ビット版では、time_t は64ビットとなっており、OS自身も64ビットのアプリケーション群も約2920億年間正しく動作する。64ビット版Solarisで既存の32ビットアプリケーションを動作させることもできるが、その場合は問題が残ったままである。一部ベンダーは標準の time_t はそのままにして、64ビットの代替データ型とそれを使用するAPIを別途用意している。NetBSDでは、次のメジャーバージョンである 6.x で32ビット版でも time_t を64ビットに拡張することを決定した。従来の32ビットの time_t を使用しているアプリケーションは、バイナリ互換性レイヤーを作って対応する。