首页 文章

作为签名整数的时间

提问于
浏览
1

我一直在阅读Y2038 problem,我明白 time_t 最终将恢复到最低可表示的负数,因为它会尝试"increment"符号位 .

根据该Wikipedia页面,无法将 time_t 更改为无符号整数,因为它会破坏处理早期日期的程序 . (这是有道理的 . )

但是,我不明白为什么它首先没有成为无符号整数 . 为什么不将1970年1月1日存储为零而不是一些荒谬的负数?

3 回答

  • 0

    因为让它从带符号-2,147,483,648开始等同于让它从无符号0开始 . 它不会改变32位整数可以容纳的值的范围 - 32位整数可以容纳4,294,967,296个不同的状态 . 问题不是起点,问题是整数可以保持的最大值 . 缓解问题的唯一方法是升级到64位整数 .

    另外(正如我刚才意识到的那样):1970年被设定为0,所以我们也可以及时回到过去 . (当时回到1901年似乎已经足够了) . 如果他们没有签名,这个时代将于1901年开始,能够从1970年开始,我们将再次遇到同样的问题 .

  • 5

    这里有一个比使用无符号值更基本的问题 . 如果我们使用无符号值,那么我们只能获得一点计时 . 这将产生明显的积极影响 - 它会使我们能够保留的时间增加一倍 - 但是后来我们将来会遇到很多问题 . 更一般地说,对于任何固定精度的整数值,我们都会遇到这些问题 .

    当UNIX在20世纪70年代开发时,拥有60年的时钟听起来不错,但显然120年的时钟会更好 . 如果他们使用了更多的比特,那么我们会有更长的时钟 - 比如说1000年 - 但是在那么多时间过后我们又回到同一个约束中并且可能会回想并说“为什么不呢?用更多的东西?“

  • 2

    因为并非所有系统都必须纯粹处理“过去”和“未来”的 Value 观 . 即使在70年代,当Unix被创建并定义了时间系统时,他们不得不在60年代或更早的时候处理日期 . 因此,有符号整数是有道理的 .

    一旦每个人都切换到64位time_t,我们就不必担心另外20亿年左右的期间会出现y2038k型问题 .

相关问题