作为有符号整数的时间
我一直在阅读Y2038问题，并且我了解time_t 最终将恢复为可表示的最低负数，因为它会尝试“递增”符号位。
根据该维基百科页面，无法将 time_t 更改为无符号整数，因为这会破坏处理早期日期的程序。 （这是有道理的。）
但是，我不明白为什么它首先没有被制成无符号整数。为什么不将 1970 年 1 月 1 日存储为零而不是一些可笑的负数呢？
I've been reading up on the Y2038 problem and I understand that time_t will eventually revert to the lowest representable negative number because it'll try to "increment" the sign bit.
According to that Wikipedia page, changing time_t to an unsigned integer cannot be done because it would break programs that handle early dates. (Which makes sense.)
However, I don't understand why it wasn't made an unsigned integer in the first place. Why not just store January 1, 1970 as zero rather than some ridiculous negative number?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
因为让它从有符号的 −2,147,483,648 开始相当于让它从无符号的 0 开始。它不会改变 32 位整数可以保存的值的范围 - 32 位整数可以保存 4,294,967,296 种不同的状态。问题不是起点，问题是整数可以容纳的最大值。缓解该问题的唯一方法是升级到 64 位整数。
另外（我刚刚意识到）：1970 年被设置为 0，所以我们也可以回到过去。 （当时回溯到 1901 年似乎就足够了）。如果它们没有签名，纪元将从 1901 年开始，可以从 1970 年追溯到，我们将再次遇到同样的问题。
Because letting it start at signed −2,147,483,648 is equivalent to letting it start at unsigned 0. It doesn't change the range of a values a 32 bit integer can hold - a 32 bit integer can hold 4,294,967,296 different states. The problem isn't the starting point, the problem is the maximum value which can be held by the integer. Only way to mitigate the problem is to upgrade to 64 bit integers.
Also (as I just realized that): 1970 was set as 0, so we could reach back in time as well. (reaching back to 1901 seemed to be sufficient at the time). If they went unsigned, the epoch would've begun at 1901 to be able to reach back from 1970, and we would have the same problem again.
这里有一个比使用无符号值更根本的问题。如果我们使用无符号值，那么我们只会多一点计时。这绝对会产生积极的影响——它会让我们可以保留的时间加倍——但我们在未来很晚的时候就会遇到问题。更一般地说，对于任何固定精度整数值，我们都会遇到这样的问题。
当 UNIX 在 20 世纪 70 年代开发时，使用 60 年的时钟听起来不错，但显然使用 120 年的时钟会更好。如果他们使用了更多的位，那么我们就会有一个更长的时钟——比如说 1000 年——但在这么长时间过去之后，我们就会回到同样的困境，并且可能会回想起来说“为什么他们不这样做？”使用更多位吗？”
There's a more fundamental problem here than using unsigned values. If we used unsigned values, then we'd get only one more bit of timekeeping. This would have a definitely positive impact - it would double the amount of time we could keep - but then we'd have a problem much later on in the future. More generally, for any fixed-precision integer value, we'd have a problem along these lines.
When UNIX was being developed in the 1970s, having a 60 year clock sounded fine, though clearly a 120-year clock would have been better. If they had used more bits, then we'd have a much longer clock - say 1000 years - but after that much time elapsed we'd be right back in the same bind and would probably think back and say "why didn't they use more bits?"
因为并非所有系统都必须纯粹处理“过去”和“未来”值。即使在 70 年代，当 Unix 创建并定义了时间系统时，他们也必须处理 60 年代或更早的日期。因此，有符号整数是有意义的。
一旦每个人都切换到 64 位 time_t，我们就不必担心另外 20 亿年左右的 136 年期间的 y2038k 类型问题。
Because not all systems have to deal purely with "past" and "future" values. Even in the 70s, when Unix was created and the time system defined, they had to deal with dates back in the 60s or earlier. So, a signed integer made sense.
Once everyone switches to 64bit time_t's, we won't have to worry about a y2038k type problem for another 2billion or so 136-year periods.