問題タブ [year2038]

私が現在書いているソフトウェアのいくつかは、30 年後に使用されると思います。しかし、その多くが 1970 年以降の秒数として時間を公開するという UNIX の伝統に基づいていることも認識しています。

実行結果は次のとおりです。

• 1970 年 1 月 1 日（木）00:00:00
• 土 8 月 30 日 18:37:08 2008
• 火曜日 1 月 19 日 03:14:07 2038
• 金 12 月 13 日 20:45:52 1901

関数 ctime()、gmtime()、および localtime() はすべて、エポック (00:00:00 UTC、1970 年 1 月 1 日; time(3) を参照) からの秒数を表す時間値を引数として取ります。

この分野でプログラマーとして何か積極的にやるべきことがあるのだろうか、それともすべてのソフトウェア システム (別名オペレーティング システム) が将来何らかの方法で魔法のようにアップグレードされると信じていいのでしょうか?

更新実際、64 ビット システムはこれから安全であるように思われます。

• 1969 年 12 月 31 日水曜日 16:00:00 PST
• 2008 年 8 月 30 日 12:02:40 PDT
• 8 月 16 日（土）23:12:55 PST 292278994
• 日 12 月 2 日 08:47:04 PST 292269055

しかし、292278994 年はどうでしょうか。

Windows 上の公式の Python 2.5 は、32 ビットの time_t を使用する Visual Studio.Net 2003 でビルドされました。したがって、年が 2038 年を超えると、例外が発生します。

これは Python 2.6 (VS2008 で time_t を 64 ビットに変更) で修正されていますが、多くのモジュールが既にコンパイルされているため、2.5 を使用したいと考えています。

ここに私の質問があります-私のプログラムが2038年を超えて公式のPython 2.5をまだ使用していることを簡単に処理できるようにする解決策はありますか? たとえば"time64"、「longtime」などの事前に作成されたライブラリなど...

2.6+ にアップグレードするように言われたり、バグを忘れたりしないでください。それを機能させる必要があるのには理由があります。そのため、ここに質問を投稿します。

私は現在、ソフトウェアが少なくとも 2050 年まで動作しなければならないという要件を持つプロジェクトに取り組んでいます。最近、NTP プロトコルの Y2.036K "バグ" と Y2.038K バグを処理する問題に遭遇しました。基本的に、当社のソフトウェアは、正しいタイム スタンプを使用して記録されたすべてのデータを使用して、これらの日付を過ぎても実行し続ける必要があります。現在、これらのバグのいずれにも解決策がないため、回避策を採用する必要があります。

これら 2 つのイベントの後もソフトウェアを実行し続け、日付を正しく記録することが重要です。OS のシステム時刻が正確であることは重要ではありません。Java を使用していることを考えると、ロールオーバー後の 1900 年のプライム エポックに関連する日付を処理できるはずです。ただし、システム時間が 1970 年の Unix エポックよりも前に設定されている場合、Java JVM は実行されません。クラッシュするだけです。

火に油を注ぐために、NTP サーバーは別のベンダーから提供されており、それを制御することはできません。したがって、別のプロトコルを使用したり、サーバーを変更してこれを処理することはできません。

クリエイティブなソリューションが必要です。言うまでもなく、いくつかの深いブードゥー教が行われなければなりません. 次のことを検討しました。

1. ntpd クライアント ソフトウェアを変更して、何らかの方法で ntp サーバーと連携し、1900 年ではなく 1970 年の Unix エポックより後の日付から現地時間をオフセットします。したがって、初期化時にクラッシュすることなく JVM を実行できます。すべてのタイム スタンプは、選択したロールオーバー日に対して相対的に処理されます。(つまり、基本的に、Unix エポックより後の日付にロールオーバーするようにしてください)。

2. ntp 修正時間が 1900 エポックにロールオーバーするのを待ち、JVM がクラッシュしないように修正を見つけます。

他の誰かがこの問題に取り組みましたか? また、私が予見できなかった他の問題が発生する可能性があり、これらの解決策のいずれかまたは両方がまったく実現不可能になる可能性はありますか?

これは、 2012 年の映画の宣伝に一部着想を得た、ちょっと気まぐれな質問ですが、ソフトウェア システムに実際に影響を与える可能性がある質問です。(2012 年でない場合は、間違いなく 2038 年になります。)

2012 年のあらゆる種類の終末予測がありますが、2012 年に期限が切れる予定の日時/タイムスタンプ システムがあるかどうか疑問に思っていました。(1年前に偶然出くわしたと思ったが、詳細は覚えていない。2038年のことも覚えているかもしれない.)

たとえば、一般的に使用される日付時刻システムは、1970 年 1 月 1 日から始まり、その時刻から秒単位でカウントされます。unsigned int の最大値を秒としてその値に追加すると、2038 年の日付になります。正確には 2038 年 1 月 19 日 3:14:07 AM です。

それで、日時システムはありますか：

エポック開始 + 一般的な int 型の最大値 = 2012 年の日付 ?

ところで、私はパラノイアの炎をあおろうとしているわけではありません。これは、実際のシステム設計の考慮事項と一致する気まぐれです。

更新ドーナツは、次の参照を含むこのページを見つけましたが、それ以上の情報はありません: 2012-07-13 Fri - UNIX time_t $50000000 at 11:01:20 UTC

何か案は？

TIMESTAMP を使用して日付と時刻を格納しようと考えていましたが、2038 年の制限があると読みました。まとめて質問するのではなく、初心者でも簡単に理解できるように、細かく分割することを好みました。だから私の質問：

1. 2038年問題とは一体何なのか？
2. なぜ発生し、発生するとどうなるのですか？
3. どうすれば解決できますか？
4. 同様の問題を引き起こさない、それを使用する代替手段はありますか?
5. TIMESTAMP を使用する既存のアプリケーションに対して、いわゆる問題が実際に発生したときに回避するにはどうすればよいでしょうか?

前もって感謝します。

タイムスタンプを使用して物を注文する Web アプリがありますが、これは単に長いだけです。私の Web アプリのバックエンドはたまたま Java で記述されているため、以下を使用しています。

これは（およそ）何年に失敗しますか？つまり、ある時点で long の範囲がオーバーフローするということですよね? 私たちは皆、とっくに死んでいるかもしれませんが、私はただ興味があります. それは再びy2kのようになりますか？これに備えるにはどうすればよいですか？ばかげている、私は知っている、ただ好奇心が強い！

2038年バグはウェブ全体にありますが、これはUNIXの問題のようです。これはJavaの日付にどのように影響しますか？

私はY2038問題time_tについて調べてきましたが、符号ビットを「インクリメント」しようとするため、最終的に表現可能な最小の負の数に戻ることを理解しています。

そのウィキペディアのページによると、time_t初期の日付を処理するプログラムが壊れるため、符号なし整数に変更することはできません。（これは理にかなっています。）

しかし、そもそもなぜ符号なし整数にしなかったのかがわかりません。ばかげた負の数ではなく、1970 年 1 月 1 日をゼロとして保存しないのはなぜですか?

PHP はミリ秒を使用して日付を表すという性質上、2038 年を過ぎた日付を表すことはできないことを理解しています。遠い将来の日付を計算したいという問題があります。何千年も離れています。

明らかに、制限のためにphp日付関数を使用してこの日付を表すことはできませんが、私は何かを持っています...私がしたいのは、年、月、日を保存することだけです。時間、分、秒、ミリ秒は気にしません。

多くの情報を破棄しても構わないと思っているので、この追加情報を含めなくても、将来のことをもっと計算できるはずだという考えは正しいでしょうか。これは現在これを行うライブラリですか？そうでない場合、この問題に取り組む方法について何かアドバイスはありますか?