2038年問題とは何ですか?

Apr 01 2000
幸い、2038年問題は、メインフレームのY2Kよりも修正がいくらか簡単です。標準時間ライブラリと、Cプログラミングがこのコンピュータの失敗にどのように関係しているかについて学びます。

2000年問題はあるため、それが受け取ったメディアの注目の大量のこれらの日ほとんどの人に理解されています。

Cプログラミング言語で書かれたほとんどのプログラムは、Y2K問題の影響を比較的受けませんが、代わりに2038年問題に悩まされています。この問題は、ほとんどのCプログラムが標準時間ライブラリと呼ばれるルーチンのライブラリを使用するために発生します。このライブラリは、時間値を格納するための標準の4バイト形式を確立し、時間値を変換、表示、および計算するための多くの関数も提供します。

標準の4バイトのフォーマットはの始まりということを前提としていた時間が12:00:00 AMで、1970年1月1日である。この値は、任意の時間/日付値がそのゼロ値以下の秒数として表現される0です。したがって、値919642718は、1970年1月1日の午前12:00:00を過ぎた919,642,718秒です。これは、1999年2月21日日曜日の太平洋時間(米国)16:18:38です。これは便利な形式です。2つの値を減算すると、それらの間の時間差である秒数が得られるからです。次に、ライブラリ内の他の関数を使用して、2回の間に何分/時間/日/月/年が経過したかを判別できます。

ビットとバイトのしくみを読んだ場合、符号付き4バイト整数の最大値は2,147,483,647であることがわかります。これが、2038年問題の原因です。負の(無効な)値にロールオーバーするまでの時間最大値は2,147,483,647で、これは2038年1月19日に変換されます。この日付に、標準時間ライブラリを使用するCプログラムで日付の計算に問題が発生し始めます。

幸い、この問題はメインフレームのY2K問題よりも修正が簡単です。適切に作成されたプログラムは、たとえば、ストレージ形式に8バイトの値を使用する新しいバージョンのライブラリを使用して簡単に再コンパイルできます。これが可能なのは、ライブラリが時間アクティビティ全体を独自の時間タイプと関数でカプセル化するためです(日付形式や計算を標準化していないほとんどのメインフレームプログラムとは異なります)。したがって、2038年問題は、Y2K問題ほど修正が難しいものではありません。

ここにいくつかの興味深いリンクがあります:

  • 2000年問題のしくみ
  • Cプログラミングのしくみ
  • ビットとバイトのしくみ
  • オペレーティングシステムのしくみ

アラートリーダーは親切にもIBMPCハードウェアが2116年の問題に苦しんでいることを指摘してくれました。以下のためにPC、時間の始まりは1980年1月1日から始まり、UNIX時間と同様に32ビットの符号なし整数の秒ずつ増加。2116年までに、整数はオーバーフローします。

Windows NTは、64ビット整数を使用して時間を追跡します。ただし、増分として100ナノ秒を使用し、時間の開始は1601年1月1日であるため、NTは2184年の問題に悩まされています。

で、このページ、AppleはMacは年間29940に大丈夫アウトであると述べています!