65

私が現在書いているソフトウェアのいくつかは、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
  • 土 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 ビット システムはこれから安全であるように思われます。

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 月 2 日 08:47:04 PST 292269055

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

4

10 に答える 10

47

32 ビット マシンでも 64 ビット時間を使用する time.h (現在は localtime()、gmtime()、mktime()、および timegm()) の移植可能な代替を作成しました。これは、time.h の代わりとして C プロジェクトにドロップされることを意図しています。これは Perl で使用されており、Ruby と Python の 2038 問題も修正する予定です。これにより、+/- 2 億 9,200 万年の安全な範囲が得られます。

コードは y2038 プロジェクトにあります。ご不明な点がございましたら、Issue Trackerに投稿してください。

「これは今後 29 年間は問題にならない」ということについては、この標準的な回答のリストをよく読んでください。要するに、物事は将来起こり、いつ起こるかを知る必要がある場合があります。また、問題、解決策ではないもの、解決策とは何かについてのプレゼンテーションも行っています。

ああ、多くの場合、システムは 1970 年より前の日付を処理しないことを忘れないでください。何かが 1970 年より前に発生したため、いつ発生したかを知る必要がある場合があります。

于 2008-10-20T02:05:35.667 に答える
17

いつでもRFC 2550を実装でき、永遠に安全です ;-)

既知の宇宙には有限の過去と未来があります。現在の宇宙の年齢は、[Zebu] で 10 ** 10 から 2 * 10 ** 10 年と推定されています。宇宙の死は、[Nigel] では 10 ** 11 - 年で発生し、[Drake] では閉じた宇宙 (ビッグ クランチ) で 10 ** 12 年、または 10 ** 14 年で発生すると推定されています。開かれた宇宙(宇宙の熱死)。

 

Y10K 準拠プログラムは、サポートする日付の範囲を宇宙の予想される寿命と一致するものに制限することを選択する場合があります。Y10K 準拠システムは、Y10K の日付を 10 ** 12 年前から 10 ** 20 年後まで受け入れなければなりません。Y10K 準拠のシステムは、過去および未来の少なくとも 10 ** 29 年間の日付を受け入れる必要があります。

于 2008-10-25T21:39:42.900 に答える
4

Visual Studio は、Visual Studio 2005 で time_t の 64 ビット表現に移行しました (後方互換性のために _time32_t は引き続き残されています)。

常に time_t に関してコードを書くように注意し、サイズについて何も想定しない限り、sysrqb が指摘するように、問題はコンパイラによって解決されます。

于 2008-08-30T18:49:06.350 に答える
1

私の年齢を考えると、年金に多額を払い、すべての部門に支払うべきだと思います。そのため、他の誰かがソフトウェアに適合する必要があります。

申し訳ありませんが、今日作成したソフトウェアの「正味現在価値」について考えても、そのソフトウェアが 2038 年に何をするかには何の影響もありません。ソフトウェア プロジェクトで数年以上の「投資収益率」が得られることはめったにありません。はるか先のことを考えるのではなく、ソフトウェアをより早く出荷することで、雇用主に多くの利益をもたらします。

唯一の一般的な例外は、将来を予測する必要があるソフトウェアです.2038年は、住宅ローンの見積もりシステムにとってすでに問題になっています.

于 2010-10-03T16:33:10.070 に答える
1

バグはそのままにしておくべきだと思います。その後、2036 年頃には、すべてをテストするために多額の費用をかけてコンサルティングを開始できます。結局のところ、1999 年から 2000 年のロールオーバーをうまく管理できたのはそのためではありません。

冗談です!

私は 1999 年にロンドンの銀行に座っていましたが、コンサルタントが Y2K でコーヒー マシンのテストを開始したのを見て非常に驚きました。あの大失敗から何か学んだことがあるとすれば、大部分のソフトウェアは問題なく動作し、残りのほとんどは失敗してもメルトダウンを引き起こさず、必要に応じてイベント後に修正できるということでした。そのため、非常に重要なソフトウェアを扱っている場合を除き、私はその時期が近づくまで特別な予防措置を講じません。

于 2009-03-25T17:42:44.843 に答える
0

2038年に向けて何をすべきか?

黙示録が来ているので、非表示にします。

しかし、真面目な話、コンパイラ (正確にはコンパイラを書いている人) がこれを処理できることを願っています。彼らはほぼ30年を過ごしました。十分な時間だと思います。

Y10K の準備はどの時点から開始しますか? ハードウェア メーカーや研究機関は、必要な新しいテクノロジに移行するための最も簡単な方法を検討しましたか?

于 2009-03-28T07:48:54.200 に答える
0

適切な文書を保管し、時間の依存関係の説明を含めてください。この移行がどれほど難しいかについて、多くの人が考えたことはないと思います。たとえば、HTTP Cookie はその日に壊れます。

于 2008-10-25T21:15:48.237 に答える
0

私は組み込みで働いており、ここにソリューションを投稿すると思いました。私たちのシステムは 32 ビットで、現在販売しているものは 30 年間の保証が付いています。つまり、2038 年のバグに遭遇することになります。将来のアップグレードは解決策ではありませんでした。

これを修正するために、カーネルの日付を現在の日付より 28 年前に設定しました。これはランダムなオフセットではありません.28年は、曜日が再び一致するのにかかる時間です. たとえば、私はこれを木曜日に書いていますが、次に 3 月 7 日が木曜日になるのは 28 年後です。

さらに、システム上の日付とやり取りするすべてのアプリケーションは、システムの日付 (time_t) をカスタムの time64_t に変換し、28 年のオフセットを正しい日付に適用します。

これを処理するカスタム ライブラリを作成しました。私たちが使用しているコードはこれに基づいています: https://github.com/android/platform_bionic

したがって、このソリューションを使用すると、余分な 28 年を簡単に購入できます。

于 2017-03-07T20:00:38.927 に答える
-1

2038 年までに、時間ライブラリはすべて 64 ビット整数を使用する必要があるため、これは実際にはそれほど大きな問題ではありません (完全にメンテナンスされていないソフトウェアでは)。

COBOL プログラムは楽しいかもしれませんが。

于 2008-08-30T18:45:45.623 に答える
-8

作用語は「すべき」です。

将来の保証を確実にする必要がある場合は、独自の日付/時刻クラスを構築してそれを使用できますが、作成したものがレガシーOSで使用されると思われる場合にのみそうします'

于 2008-08-30T18:47:16.337 に答える