当自纪元以来的秒数 > LONG_MAX 时会发生什么？答案

【问题标题】：What will happen when seconds since epoch > LONG_MAX?当自纪元以来的秒数 > LONG_MAX 时会发生什么？
【发布时间】：2012-02-22 21:25:49
【问题描述】：

对于家庭作业，我正在编写一个处理大量time_t 对象的程序。我考虑过检查它们是否溢出，但后来我想到如果它们溢出，我们都会遇到一些麻烦。

有这方面的计划吗？当 epoch 之后的时间超过存储时会发生什么？

【问题讨论】：

我怀疑是否还有任何主流 CRT 实现没有使 time_t 成为 64 位类型。
en.wikipedia.org/wiki/Year_2038_problem
@Hans：错了。 time_t 在我所知道的所有现有 32 位机器上都是 32 位 (long)，尤其是 Linux/glibc。无论如何，我认为所有 32 位机器都将在 2038 年退役是现实的……
@R.：希望我们灰胡子 C 程序员能够在 2036 年左右以惊人的高小时费率解决问题；）
@caf 很遗憾我们不能再这样做了，因为64-bit time_t support was added to Linux 5.1 and glibc 2.32

【解决方案1】：

LONG_MAX 在 64 位机器上是 2^63 - 1。试试这个：转到http://google.com 并输入2^63 seconds in years。查看答案并决定您是否真的需要担心它。

【讨论】：

喜欢喜欢喜欢。是的，这就是大数字的有趣之处。我什至想，“哦，也许它只是一个如此大的数字，我们不必担心......不，2 ^ 63秒可能不是很多年。”我对这个答案很满意。
我喜欢关于这个问题的维基百科文章。使用带符号的 64 位值会在 12 月 4 日星期日 292,277,026,596 的 15:30:08 引入新的环绕日期。至少对我来说不是问题。
想到我可能不会在近 3000 亿年后看到这种情况发生，这让我有点难过。太小了。
@Brenden 不是那种态度，你不会。 ;^)
@r_ahlskog 哦蘸！这可能会干扰我 12 月 7 日生日的计划，292,277,026,596。必须记下这一点。