it-swarm-ja.tech

2038年問題

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

28
8128

一部の長期暗号化証明書で2038年より前の日付を処理する必要がある組み込みLinuxシステムでこの問題が発生したため、この可能性はアプリケーションドメインに依存すると思います。

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

17
Alex B

数年前、30年ローンの計算を行う住宅ローンプログラムのような分野で、すでに問題の報告がありました:2008 + 30 = 2038。

9
Warren Young

これは私の意見ですが、この問題は32ビットカウンターの問題が原因です。今日、ほとんどのOSは64ビット(少なくとも64ビットコンピューター)で時間を処理するように更新されているため、すべてのOSとソフトウェアの準備が長い2038年より前に2020年としましょう。2038年に2020年からソフトウェアを実行する場合にのみ問題が発生する可能性があります。
ほとんどの場合、問題にはならないでしょう。私は願います。

8
radius

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

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

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

時間を格納する各インスタンスを再検討する必要があり、すべてのAPIが更新され、それを使用するすべてのツールも更新されます。

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

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

8
geoffc

それほど大したことではありません。

ソフトウェアとハ​​ードウェアのベンダーが販売するために製品を「Y2K準拠」として認定する必要があった最初のY2K電撃中に(PC接続のネットワークケーブルがY2K準拠として認定されたことを覚えています)、多くの企業がすべての詳細な監査を行いました、将来的にクロックを設定してテストします。

当時、テストのコストが非常に高かったため、ほとんどの場合、1/1/99(一部の開発者は99をセンチネルとして使用した可能性があります)、12/31/99、1/1 /などのいくつかの日付でテストしました00、うるうさ2000年、1/19/38、その他多数。面倒なリストについては here を参照してください。

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

1
Joel Spolsky

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

1
user55149
#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は「気付かれない」と思いますが、「プロテアリー」プラットフォーム(つまり、多数のプロテアリーソフトウェアのプラットフォーム)で問題が発生すると予想します。

0

Y2Kのようなものであれば、すでに影響を受けてソフトウェアを変更している人もいますが、ほとんどの開発者は2030年代、おそらく2035年頃までそれを無視します。 K&R Cを知っていて、まだ老朽化が進んでいないと、突然大金を請け負うことができます。実際の移行では、まだ行われていない多くのことが示されますが、おそらくそれほど重要ではありません。

0
David Thornley