今から対策をしないと、2038年12時14分08秒に、PC世界が破滅するかもしれません。いや、絶対します。
C言語系のプログラムは、2038年までしかもたないのです。
プログラムには限界があります。
標準的なC言語の実装では、時刻の表現形式として1970年1月1日0時0分0秒（UTC）からの経過秒数[1]を使用している。これはUNIXの仕様に由来するもので、time_t型という。
C言語の規格を定めた「ISO/IEC 9899:1999」では、time_t型の範囲や精度はいずれも処理系依存としているが、[2]time_t型は、伝統的には符号つき32ビット整数（signed long int型）であり、最大値は (231 - 1) = 2,147,483,647 となる。つまり、2,147,483,647秒までしか計算できない。
このようなAPIの下で作られたアプリケーションでは、1970年1月1日0時0分0秒から2,147,483,647秒を経過した、2038年1月19日3時14分7秒を越えると、この値がオーバーフローし、負と扱われるため、誤作動する可能性が高い。さらに、この仕様は他の多くのプログラミング言語でも採用されているため、それらの言語で作られたアプリケーションも同様に誤作動する可能性が高い。
また、ファイルシステムのext2、ext3、ReiserFSのタイムスタンプも同日付までしか対応していない。
ただし、この期日以前でもプログラムで内部的にこの秒数を超えた時刻データを扱おうとすれば同様のエラーが発生するため、2004年1月11日にはすでにATMの誤作動といったトラブルが発生した（プログラム中に現在時刻を2倍する式があったため、2,147,483,647秒の半分以上経過した時点で誤動作が発生した）。他にも顕在化していないトラブルが今後表面化するという可能性はあり得る。
以下のような理由により、2000年問題より深刻であるという指摘もある。
2000年問題はアプリケーションレベルでの修正が可能であったが、この問題は現在普及しているC言語処理系の実装による。
「32ビットの符号付二進数の桁あふれ」という理由を理解するには、ある程度の専門知識を必要とするので、一般大衆、経営者、政治家などの理解と関心を得にくい可能性がある。
2000年問題のように暦年の変わり目というキリのよいときに地域の標準時に応じて波状的に問題の時刻が世界を巡るのではなく、ごく中途半端な時刻に世界同時に一斉に問題の時刻が訪れるので、もし問題が生じた場合は対応するための人的資源の確保がより困難となる可能性がある。
対策としては、time_t型を符号つき64ビット整数型（一般にはlong long int型）にするという方法がある。符号つき64ビット整数型の場合、上限は9,223,372,036,854,775,807（263 - 1）である。
しかし、2038年問題と同じように考えると、292277026596年に桁あふれが起こる可能性があり、これを「292277026596年問題」と呼ぶこともある。ただ、符号つき64ビット整数型は、上記の通り、292277026596年（西暦3000億年近く）まで使用できるので、この問題は宇宙の歴史（推定137億年）の20倍から21倍ほどの時間が経過しないと発生しない。西暦10000年問題と同じく、真面目な話ではなく、一種のジョークとして語られている。
最近のオペレーティングシステムや処理系では、time_t型は符号つき64ビット整数型で表されるようになってきている。
秒数を2倍して計算すると桁数がオーバーフローしてしまうため元に戻しても結果がおかしくなる。半分になるのは1,073,741,824秒目であり、2004年1月10日13時37分4秒となる。
2001年9月9日問題は、2001年9月9日にtime_t型の値が999,999,999秒から1,000,000,000秒と桁が増えることに伴う問題。
NTPやMicrosoft Windowsなど、1900年1月1日からの積算秒数で時間を表現するシステムもあり、符号なし32ビットの値が2036年2月6日にオーバーフローすることによって問題が発生する（→2036年問題）。
対策をしないとほんとうにひどい目に遭う。
人気ブログランキングに登録しています！！！！
↓愛のクリックを！！↓
C言語系のプログラムは、2038年までしかもたないのです。
プログラムには限界があります。
標準的なC言語の実装では、時刻の表現形式として1970年1月1日0時0分0秒（UTC）からの経過秒数[1]を使用している。これはUNIXの仕様に由来するもので、time_t型という。
C言語の規格を定めた「ISO/IEC 9899:1999」では、time_t型の範囲や精度はいずれも処理系依存としているが、[2]time_t型は、伝統的には符号つき32ビット整数（signed long int型）であり、最大値は (231 - 1) = 2,147,483,647 となる。つまり、2,147,483,647秒までしか計算できない。
このようなAPIの下で作られたアプリケーションでは、1970年1月1日0時0分0秒から2,147,483,647秒を経過した、2038年1月19日3時14分7秒を越えると、この値がオーバーフローし、負と扱われるため、誤作動する可能性が高い。さらに、この仕様は他の多くのプログラミング言語でも採用されているため、それらの言語で作られたアプリケーションも同様に誤作動する可能性が高い。
また、ファイルシステムのext2、ext3、ReiserFSのタイムスタンプも同日付までしか対応していない。
ただし、この期日以前でもプログラムで内部的にこの秒数を超えた時刻データを扱おうとすれば同様のエラーが発生するため、2004年1月11日にはすでにATMの誤作動といったトラブルが発生した（プログラム中に現在時刻を2倍する式があったため、2,147,483,647秒の半分以上経過した時点で誤動作が発生した）。他にも顕在化していないトラブルが今後表面化するという可能性はあり得る。
以下のような理由により、2000年問題より深刻であるという指摘もある。
2000年問題はアプリケーションレベルでの修正が可能であったが、この問題は現在普及しているC言語処理系の実装による。
「32ビットの符号付二進数の桁あふれ」という理由を理解するには、ある程度の専門知識を必要とするので、一般大衆、経営者、政治家などの理解と関心を得にくい可能性がある。
2000年問題のように暦年の変わり目というキリのよいときに地域の標準時に応じて波状的に問題の時刻が世界を巡るのではなく、ごく中途半端な時刻に世界同時に一斉に問題の時刻が訪れるので、もし問題が生じた場合は対応するための人的資源の確保がより困難となる可能性がある。
対策としては、time_t型を符号つき64ビット整数型（一般にはlong long int型）にするという方法がある。符号つき64ビット整数型の場合、上限は9,223,372,036,854,775,807（263 - 1）である。
しかし、2038年問題と同じように考えると、292277026596年に桁あふれが起こる可能性があり、これを「292277026596年問題」と呼ぶこともある。ただ、符号つき64ビット整数型は、上記の通り、292277026596年（西暦3000億年近く）まで使用できるので、この問題は宇宙の歴史（推定137億年）の20倍から21倍ほどの時間が経過しないと発生しない。西暦10000年問題と同じく、真面目な話ではなく、一種のジョークとして語られている。
最近のオペレーティングシステムや処理系では、time_t型は符号つき64ビット整数型で表されるようになってきている。
秒数を2倍して計算すると桁数がオーバーフローしてしまうため元に戻しても結果がおかしくなる。半分になるのは1,073,741,824秒目であり、2004年1月10日13時37分4秒となる。
2001年9月9日問題は、2001年9月9日にtime_t型の値が999,999,999秒から1,000,000,000秒と桁が増えることに伴う問題。
NTPやMicrosoft Windowsなど、1900年1月1日からの積算秒数で時間を表現するシステムもあり、符号なし32ビットの値が2036年2月6日にオーバーフローすることによって問題が発生する（→2036年問題）。
対策をしないとほんとうにひどい目に遭う。
人気ブログランキングに登録しています！！！！
↓愛のクリックを！！↓
