为什么我们不使用完整的32位来存储自Epoch以来的136年？

Question

我见过很多次，例如在UNIX上，在MySQL timestamp等：纪元开始于1970-1-1，但最高记录的一年是2038年。现在让我算：

2^32/60/60/24/365+1970 
2106 

所以，如果我们使用完整的32位，我们自然会得到到2106年没有任何问题。但显然2038年只对应31位。那么，为什么我们抛出一点呢？通过使用完整的32位，我们可以希望我们不必解决问题，因为我们可能会首先摧毁地球......

对评论的反应：当然这是因为它已签名，但为什么会有时间戳必须签字？这是这个问题的关键。

Answer 1

这听起来很疯狂，但人们可能想要表示1970年之前的日期。切换对经典time_t值的解释只会导致麻烦。

2038问题可以通过切换到具有相同规格的64位表示来侧置。究竟应该如何进行是有争议的，因为能够代表未来几十亿年的日期具有可疑价值，因为这种精度可以用来代表亚秒级时间，但天真的解决方案比没有什么更好。

简短的回答是：我们使用一个有符号的值，因为这就是标准。

Answer 2

这可能在“为什么time_t的签署，而不是无符号”在这种情况下，你可能有兴趣在听到这背后这里的原因属于：

这里原是一些争论了Unix的time_t是否应该 有符号或无符号。如果未签名，未来的范围将翻倍， 推迟32位溢出（68年）。然而，这将是 无法代表1970年以前的时间。丹尼斯里奇，当被问及有关 这个问题时，说他没有深入思考这个问题，但认为有能力代表所有时间在他一生中会是 不错。 （里奇出生于1941年，Unix时间为− 893 400 000.） 共识是time_t被签署，这是通常的做法。用于QNX操作系统版本6的 软件开发平台具有 无符号的32位time_t，尽管旧版本使用带符号的类型。