2038年問題[クローズ]

2038年問題が非常に問題になる可能性はどのくらいですか？

いくつかの長期暗号証明書で2038年を超える日付を処理する必要がある組み込みLinuxシステムでこの問題に遭遇したため、この可能性はアプリケーションドメインに依存すると思います。

ほとんどのシステムは2038年よりも前に準備ができているはずですが、今日の日付を計算するのがずっと先である場合は、問題が発生している可能性があります。

これは重大な問題になると思います。影響を受けるコードは一般に低レベル（CTIME）であるため、1999/2000のY2Kの問題よりもはるかに有害です。

さらに問題を複雑にするのは、Y2Kが湿ったスクイブであると認識されていたという事実により、イベントへの準備段階で問題に注意を向けることが難しくなることです。

文化的な参照：

Cory Doctorowは、オープンライセンスの下で短編コンミッショニング/パブリッシングの新しいモデルを試していましたが、そのうちの1つに2038のテーマを提案しました。彼はEpochで見事にそれを行いました：http : //craphound.com/?p=2337

数年前、30年ローンの計算を行っている住宅ローンプログラムなどの分野で、問題がすでに報告されていました：2008 + 30 = 2038。

64ビットOSは、最終的には2037問題とは無関係です。（CTIMEは2038年よりも2037年に近くなります）。

問題はOSのビット深度ではなく、OSが時間をどのように保存するかです。または、データベース列はどのように時間を保存することを選択しますか。または、このディレクトリサービスは、バックエンドで時間構文属性の時間をどのように保存しますか。

これは、32ビットのタイムカウンターを使用することが非常に一般的であるため、人々が考えるよりもはるかに大きな問題です。

時間を保存する各インスタンスを再確認し、すべてのAPIを更新し、それを使用するすべてのツールも更新する必要があります。

書き出された生データの代わりに、人間が読める形式で時間を設定できる抽象化レイヤーにより、簡単になりますが、これは1つのケースにすぎません。

これは、ほとんどの人が考えるよりもはるかに大きな取引になると思います。

これは私の意見ですが、この問題は32ビットカウンターの問題によるものです。今日、ほとんどのOSは64ビット（少なくとも64ビットコンピューター）で時間を処理するように更新されています。つまり、2038年まで
にソフトウェアを実行している場合にのみ問題が発生する可能性があります。ほとんどの場合、問題になるとは限りません。私は願います。

そんなに大したことじゃない。

最初のY2Kブリッツでは、ソフトウェアおよびハードウェアベンダーが製品を販売するために「Y2K準拠」であると認定する必要がありました（PC接続のネットワークケーブルがY2K準拠であると認定されていることを覚えています） 、将来的にクロックを設定してテストします。

当時、テストのコストは非常に高かったため、ほとんどの場合、1/1/99（一部の開発者は99を番人として使用した可能性があります）、12/31 / 99、1 / 1 / 00、2000年の跳躍、1/19/38、およびその他多数。退屈なリストはこちらをご覧ください。

したがって、1999年に存在した重要なソフトウェアにはおそらく2038個のバグはないと思いますが、それ以来、無知なプログラマーによって書かれた新しいソフトウェアにはバグがあると思います。Y2K全体の大失敗プログラマーは一般に、日付エンコードの問題をはるかに意識するようになったため、Y2K（それ自体が反クライマックスのようなもの）ほど大きな影響を与えることはないでしょう。

それまでに実行されている32ビットシステムが問題になります。

#include <time.h>
#include <stdio.h>

int main() {
  time_t t = (time_t)(1L << (sizeof(time_t)*8 - 9));
  printf("%d\n", sizeof(time_t));
}

9ではなく1にする必要がありますが、ctimeはより大きな日付を処理しません。

8 - Sun Jun 13 07:26:08 1141709097

私のシステム（もちろん64ビット）の時間は、さらに100万年も実行できます。解決策は、システムを64ビットに更新することです。

キャッチは、プログラムがそれを処理しない可能性があることです。特に古く、財産的で、維持されていません。開発者は次の事実に慣れています：

• intは32ビットです（実際には、常に32ビットであると想定されているため、64ビットシステムでは32ビットとして保存されます）
• ほとんどのタイプ（などtime_t）は安全にキャストできますint

一般的なFLOSSソフトウェアでは、おそらく両方が「多目」のレビューを通過しません。あまり人気がなく所有権のあるものでは、著者に大きく依存します。

無料の* nixの世界では、2038は「見過ごされて」しまいますが、「プロプライエタリ」プラットフォーム（つまり、多数のプロプライエタリソフトウェアを使用するプラットフォーム）で問題が発生します。

Y2Kのようなものである場合、一部の人々はすでに影響を受けてソフトウェアを変更していますが、ほとんどの開発者は2030年代、おそらく2035年頃までそれを無視します。 K＆R Cを知り、まだ老いすぎていないことを知ると、突然多額のお金で契約できます。実際の移行では、まだ行われていない多くのこと、おそらくそれほど重要ではないことの多くが表示されます。

Y2Kの問題は、4年ではなく、年を表す2つの憲章でした。

多くのシステムは2000を1900と区別する方法がありませんでした。なぜなら、それらは '00'のみを保存したからです。

ほとんどすべてのシステムは、現在、年を格納するために4文字を使用するか、何らかのライブラリを使用します。

そのため、すべての人が10000年（Y10K）を心配することになります。OSおよびライブラリライターを除く...