4

私は現在、ソフトウェアが少なくとも 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 がクラッシュしないように修正を見つけます。

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

4

1 に答える 1

3

64ビットJVMを使用する64ビットLinuxにソフトウェアをインストールします。time_t友達はここで64ビットです。2038年以降の時間を調整して、まだ機能するかどうかを確認してください。よろしければ、NTPを破棄し、正確なクロックとして使用できるgpsまたはその他のソースを見つけて、32ビットの問題がないことを保証し、ソフトウェアをインターフェイスして、そこから時刻を読み取り/同期します。

于 2009-09-09T17:36:13.973 に答える