time - 符号付き整数としての時間

Question

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

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

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

Answer 1

符号付き-2,147,483,648で開始することは、符号なし0で開始することと同じです。32ビット整数が保持できる値の範囲は変更されません。32ビット整数は4,294,967,296の異なる状態を保持できます。問題は出発点ではなく、整数が保持できる最大値です。この問題を軽減する唯一の方法は、64ビット整数にアップグレードすることです。

また（私がちょうど気付いたように）：1970年は0に設定されていたので、私たちも時間を遡ることができました。（当時、1901年に遡るだけで十分だったようです）。彼らが署名されていない場合、エポックは1901年に始まり、1970年から戻ることができるようになり、同じ問題が再び発生します。

Answer 2

ここには、符号なしの値を使用するよりも根本的な問題があります。符号なしの値を使用した場合、もう1ビットの計時しか得られません。これは間違いなくプラスの影響を及ぼします-それは私たちが保つことができる時間を2倍にするでしょう-しかしそれから私たちはずっと後に問題を抱えることになるでしょう。より一般的には、固定精度の整数値の場合、これらの線に沿って問題が発生します。

UNIXが1970年代に開発されていたとき、60年の時計を持っていれば問題ないように聞こえましたが、明らかに120年の時計の方が良かったでしょう。彼らがより多くのビットを使用した場合、私たちははるかに長い時計（たとえば1000年）を持っていたでしょうが、その多くの時間が経過した後、私たちは同じバインドに戻って、おそらく振り返って「なぜ彼らはしなかったのですか？もっとビットを使いますか？」

Answer 3

すべてのシステムが純粋に「過去」と「将来」の値を処理する必要があるわけではないためです。70年代でさえ、Unixが作成され、時間システムが定義されたとき、彼らは60年代以前の日付に対処しなければなりませんでした。したがって、符号付き整数は理にかなっています。

全員が64ビットtime_tに切り替えると、さらに20億かそこらの136年間、y2038kタイプの問題について心配する必要がなくなります。