私はY2038 problemを読んできましたが、time_tは符号ビットを "インクリメント"しようとするため、最終的に負の数値に戻すことを理解しています。符号付き整数としての時間
そのウィキペディアのページによると、time_tを符号なし整数に変更することは、早期の日付を処理するプログラムを壊すため、実行できません。 （それは理にかなっています）。
しかし、なぜ私は最初に符号なし整数になっていないのか分かりません。 1970年1月1日をちょっとばかげた負の数ではなくゼロとして保存するだけではどうですか？
signed -2,147,483,648で始めることは、符号なし0で始めることと同じです。32ビット整数が保持できる値の範囲は変更されません.32ビット整数は4,294,967,296の異なる状態を保持できます。問題は出発点ではなく、問題は整数が保持できる最大値です。問題を緩和する唯一の方法は、64ビット整数にアップグレードすることです。
また、1970年代は0に設定されていたため、時とともに戻ってきました。 （1901年まではその時に十分だったと思われる）。彼らが署名されていなければ、1970年から1901年に始まり、同じ問題が再び起こるでしょう。
すべてのシステムが純粋に「過去」および「将来」の値を処理する必要はないため。 70年代になっても、Unixが作成され、時間システムが定義されたときには、60年代以前の日付に対処しなければなりませんでした。したがって、符号付き整数は理にかなっていました。
誰もが64bit time_tに切り替えると、さらに20億分の136年の間、y2038kタイプの問題について心配する必要はありません。
ここでは、符号なしの値を使用するよりも根本的な問題があります。符号なしの値を使用した場合は、さらに1ビットの計時を取得します。これは明らかにプラスの効果をもたらします。これは、時間を2倍にすることができますが、将来は後で問題が発生します。より一般的には、固定精度整数値の場合、これらの行には問題があります。
UNIXが1970年代に開発されていたとき、60年のクロックがうまくいきましたが、明らかに120年のクロックが良いでしょう。彼らがより多くのビットを使用していたなら、もっと長い時計、例えば1000年という時間がありましたが、それ以後、多くの時間が経過すると、同じバインドですぐに戻ってくると思います。より多くのビットを使用しますか？
そのように書いた人はそれが問題ではないと知っていたからですか？ ;） –