64位Ubuntu系统的时间戳记，2038年问题

我正在使用64位Ubuntu系统。

我目前正在研究一个包含MariaDB的项目。我打算在项目中引入时间戳技术，以便人们可以在不同时区获得正确的时间。

我听说过一些有关2038年时间戳的文章。许多文章建议我们使用64位系统来购买更多“时间”。

这个“位”指的是多少时间？对我们来说，足够长的时间才能管理Web应用程序直到结束？如果不是这种情况，是否只是像两年的延期，所以当2040年到来时，我们是否将拥有无法正常运行的应用程序？

14.04 64-bit time

— 春节
source

使用64位time_t整数的64位系统将为您提供更多的时间-直到12月4日星期日15:30:08 292,277,026,596。希望它对您的应用程序足够长；）

— 罗恩（Ron

它不会给您更多的“好处”。它给您多了32位。

— user12205

64位时间戳是这些权宜之计之一。在1亿亿欧元的乌托邦计划中工作的人呢？他们也将需要功能正常的计算机系统！使用128位时间戳使我们不仅可以从宇宙的这次迭代中而且从许多其他许多事物中唯一地标识任何时间。

— Blacklight Shining

由于您从未在此站点上接受任何答案，因此：如果以下某个答案对您有所帮助，请不要忘记单击其文本左侧的灰色☑，这表示是的，此答案有效！ ;-)

— Fabby 2015年

Answers:

好吧，如果可以选择购买一个“位”，即从一个有符号的32位整数转换为一个无符号的32位整数，那么事情就一直持续到2106年。

转移到64位是“更好”。您可以获得数千亿年的分辨率。

Ubuntu这样做：

$ uname -p
x86_64

$ date --date=9090-01-01 +%s
224685532800

但是，这就是操作系统级别。仅仅因为Ubuntu在其时间上使用64位整数并不意味着MySQL / MariaDB将使用它来存储其时间戳。如果2038年以后的日期对您现在很重要，请立即开始测试。

实际上，我可以为您节省一些时间。还是坏了。该错误已在十年前报告，但其主要测试仍无法通过64位int进行。

mysql> select from_unixtime(2548990800);
+---------------------------+
| from_unixtime(2548990800) |
+---------------------------+
| NULL                      |
+---------------------------+
1 row in set (0.00 sec)

这甚至不是存储。这有点可悲。

（是的，它在MariaDB 10.1版上运行）

— 奥利
source

十年过去了，他们还有22年的时间来解决它。<交叉手指> ...

— Mindwin

注意：使用无符号的32位整数是一种hack。

— 凯文（Kevin）

根本不要将其存储为整数。将其存储为ISO 8601格式的日期字符串。这是整个Internet使用的标准格式。

9999-12-31T23:59:59+00:00

— 多比
source

让我们为Year10K Bug举杯吧！;）但是，实际上，虽然字符串确实是可扩展的，但是它们却相对较大（您的示例是200位！），并且解析和处理原始数字的速度快了数十亿倍。那很重要。

— 奥利（Oli）

这是一种很好的显示格式-仅用于此目的。对于其他任何事情（也就是处理数据直到决定将其格式化为用户的最后一刻），例如比较，算术等。Unix时间戳作为整数（或浮点数）要好得多。

— egmont

@Oli重要，如果确实重要。当时间早于UNIX时代时，此解决方案不会失败。该格式是协议和API中整个Internet上用于日期的标准。如果要在MariaDB列中存储某些内容，那么实际上，这就是应该将其存储在磁盘上的方式。当然，在内存中，也许您想将其存储到更合适的数据结构中。如果您始终使用UTC，则不需要最后40位。

— dobey