2038年に向けて何をすべきでしょうか？
https://stackoverflow.com/questions/36239
-
09-06-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russian質問
今日私が書いているソフトウェアのいくつかは 30 年後にも使用されるだろうと考えたいと思います。しかし、その多くは 1970 年以来時間を秒数として表示するという UNIX の伝統に基づいていることも私は知っています。
#include <stdio.h>
#include <time.h>
#include <limits.h>
void print(time_t rt) {
struct tm * t = gmtime(&rt);
puts(asctime(t));
}
int main() {
print(0);
print(time(0));
print(LONG_MAX);
print(LONG_MAX+1);
}
実行すると次の結果が得られます。
- 1970 年 1 月 1 日木曜日 00:00:00
- 2008 年 8 月 30 日土曜日 18:37:08
- 1月19日火曜日 03:14:07 2038
- 12月13日(金) 20:45:52 1901
関数 ctime()、gmtime()、および localtime() はすべて、エポック (1970 年 1 月 1 日 00:00:00 UTC) からの時間を秒単位で表す時間値を引数として受け取ります。時間(3)を参照)。
プログラマーとしてこの分野で積極的にやるべきことはあるのだろうか、それともすべてのソフトウェア システム (別名オペレーティング システム) が将来魔法のようにアップグレードされると信じるべきでしょうか?
アップデート このことから、確かに 64 ビット システムは安全であるように思われます。
import java.util.*;
class TimeTest {
public static void main(String[] args) {
print(0);
print(System.currentTimeMillis());
print(Long.MAX_VALUE);
print(Long.MAX_VALUE + 1);
}
static void print(long l) {
System.out.println(new Date(l));
}
}
- 1969 年 12 月 31 日水曜日 16:00:00 PST
- 2008 年 8 月 30 日（土）12:02:40 PDT
- 8月16日（土）23:12:55 PST 292278994
- 12月02日（日）08:47:04 PST 292269055
しかし、292278994 年はどうでしょうか?
解決
私は、32 ビット マシンでも 64 ビット時間を使用する time.h (現在は localtime()、gmtime()、mktime()、および timegm() のみ) の移植可能な代替プログラムを作成しました。これは、time.h の代替として C プロジェクトに組み込まれることを目的としています。これは Perl で使用されており、Ruby と Python の 2038 の問題もこれで修正するつもりです。これにより、+/- 2 億 9,200 万年の安全な範囲が得られます。
コードを見つけることができます 2038年プロジェクトで. 。ご質問がございましたら、お気軽に投稿してください。 問題トラッカー.
「あと 29 年間は問題ない」については、こちらをよく読んでください。 標準的な回答のリスト それに。つまり、物事は将来起こるものであり、それがいつ起こるかを知る必要がある場合があります。私も持っています 問題に関するプレゼンテーション、何が解決策ではないのか、何が解決策なのか.
ああ、多くの場合、システムは 1970 年より前の日付を処理できないことを忘れないでください。物事は 1970 年より前に起こったものであり、それがいつなのかを知る必要がある場合があります。
他のヒント
いつでも実装できる RFC2550 そして永遠に安全でいてください ;-)
既知の宇宙には有限の過去と未来があります。宇宙の現在の年齢は、[Zebu]で10 ** 10から2 * 10 ** 10歳の間で推定されています。宇宙の死は、[nigel]で10 ** 11 -年で発生し、[ドレイク]で発生すると推定されています。開いた宇宙（宇宙の熱の死）。
Y10K準拠のプログラムは、宇宙の予想される生活と一致するものにサポートする日付の範囲を制限することを選択する場合があります。Y10K準拠システムは、Y10K日付を過去の10年12年から将来の10 ** 20年に受け入れる必要があります。Y10K準拠のシステムは、過去および未来で少なくとも10 ** 29年の日付を受け入れる必要があります。
Visual Studio は、Visual Studio 2005 で time_t の 64 ビット表現に移行しました (ただし、下位互換性のために _time32_t は残されています)。
常に time_t の観点からコードを書くように注意し、サイズについて何も想定しない限り、sysrqb が指摘するように、問題はコンパイラによって解決されます。
バグは残しておいたほうがいいと思います。そして 2036 年頃には、あらゆるものをテストするためのコンサルタント会社を多額の資金で販売し始めることができます。結局のところ、それが私たちが 1999 年から 2000 年のロールオーバーに成功した方法ではないでしょうか。
冗談だよ！
1999 年にロンドンの銀行に座っていた私は、コンサルタントが Y2K コーヒー マシンのテストを開始しているのを見て非常に驚きました。あの大失敗から私たちが何かを学んだとすれば、大部分のソフトウェアは正常に動作し、残りのほとんどは失敗してもメルトダウンを引き起こすことはなく、必要に応じてイベント後に修正できるということだと思います。そのため、私はその時がかなり近づくまで特別な予防策は講じません。
私の年齢を考えると、私は自分の年金とすべての部門の給与を多額に支払うべきだと思います。そのため、他の誰かがソフトウェアを適合させる必要があります。
申し訳ありませんが、あなたが現在作成しているソフトウェアの「正味現在価値」を考えてみると、2038 年にそのソフトウェアが何をするかには何の影響もありません。ソフトウェア プロジェクトでは、数年以上の「投資収益率」は珍しいため、そこまで先のことを考えるよりも、ソフトウェアをより早く出荷できるようにすることで、雇用主はより多くの利益を得ることができます。
唯一の一般的な例外は、将来を予測する必要があるソフトウェアであり、住宅ローン見積システムでは 2038 年がすでに問題になっています。
適切な文書を保管し、時間の依存関係の説明を含めてください。この移行がどれほど困難であるかについて考えたことのある人は多くないと思います。たとえば、その日に HTTP Cookie が壊れる可能性があります。
2038年に向けて何をすべきでしょうか？
黙れ、黙示録が来るから。
しかし真剣に、コンパイラ (正確にはコンパイラを作成する人) がこれを処理できることを願っています。彼らには30年近くの時間があります。十分な時間だと思います。
10,000 円の準備はいつから始めればよいでしょうか?ハードウェアのメーカーや研究所は、そのために必要となる新しいテクノロジーに移行する最も簡単な方法を検討したことはありますか?
私は組み込み関連の仕事をしているので、ここにソリューションを投稿したいと思いました。私たちのシステムは 32 ビットで、現在販売している製品には 30 年間の保証が付いています。これは、2038 年のバグに遭遇することを意味します。将来アップグレードすることは解決策ではありませんでした。
これを修正するために、カーネルの日付を現在の日付より 28 年前に設定しました。これはランダムなオフセットではなく、28 年は曜日が再び一致するまでにかかる時間です。たとえば、私はこれを木曜日に書いていますが、次に3月7日が木曜日になるのは28年後です。
さらに、システム上の日付を操作するすべてのアプリケーションは、システム日付 (time_t) を取得してカスタム time64_t に変換し、28 年のオフセットを正しい日付に適用します。
これを処理するカスタム ライブラリを作成しました。私たちが使用しているコードはこれに基づいています。 https://github.com/android/platform_bionic
したがって、このソリューションを使用すると、さらに 28 年を簡単に購入できます。
2038 年までに、時間ライブラリはすべて 64 ビット整数を使用するようになるため、これは実際にはそれほど大きな問題ではなくなります (完全にメンテナンスされていないソフトウェアでは)。
COBOL プログラムは楽しいかもしれません。
操作的な単語は「べきである」です。
将来性を保証する必要がある場合は、独自の日付/時刻クラスを構築してそれを使用できますが、作成した内容がレガシー OS で使用されると考えられる場合にのみそうします。
