我今天可以在我的代码中做什么，以防止 2038 年的 unix 时间戳用完？答案

【问题标题】：What can I do in my code today, to prevent the unix time stamp running out in 2038?我今天可以在我的代码中做什么，以防止 2038 年的 unix 时间戳用完？
【发布时间】：2013-01-17 19:06:10
【问题描述】：

例如，我主要使用 PHP 进行编程。我今天能做些什么来防止我的程序在 2038 年由于 unix 时间戳耗尽而爆炸？我很想看到一些特定的算法、函数或逻辑可以用来防止这个问题。谢谢。

【问题讨论】：

你认为你今天写的代码在 2038 年还会继续使用吗？
到时候使用 64 位电脑。这应该不需要额外的努力。
@Dagon - 70 年代的程序员也不认为他们的代码会在 2000 年被使用，但是你瞧……
@Jan - 你编程时间不长吧 :) 我在 1998 年和 1999 年的整个时间里都在对 70 年代编写的 VAX VMS 程序进行 Y2K 修复。我可以肯定地告诉你，还有成千上万的其他程序员浪费了数百万小时来确保“2000 年 1 月 1 日没有真正发生任何事情”。
@Dagon 在 1970 年，当我得到第一份编程工作时，我确实担心 2000 年。直到 1990 年代后期我才停止担心，当担心它并因此修复它时，它变得时髦。

标签： php algorithm unix time

【解决方案1】：

将时间戳存储为 64 位或更高的整数。我确信届时 MySQL 将被更新，因此 TIMESTAMP 不是 32 位的。关于 PHP，如果您使用的是 64 位服务器，我看不到任何问题。

【讨论】：

这是否意味着不使用PHP的构建日期功能？还是您希望 PHP 日期函数在 2038 年之后更新以工作？
什么意思？为什么你认为日期功能在 2038 年之后不起作用？
当前 PHP 日期函数明确表示：“时间戳的有效范围通常是从 1901 年 12 月 13 日星期五 20:45:54 GMT 到 2038 年 1 月 19 日星期二 03:14:07 GMT。 "
@KoKo "时间戳的有效范围通常从 1901 年 12 月 13 日星期五 20:45:54 GMT 到 2038 年 1 月 19 日星期二 03:14:07 GMT ”。 FTFY。
+1 用于启动 MySQL 等外部系统。外部系统和文件格式（如 tcpdump 数据包捕获格式）不灵活并指定暂时使用 32 位，这是真正的问题所在。对于编程语言内部表示的计算，问题将在 2038 年之前通过使用 64 位类型来解决，例如 time_t。

【解决方案2】：

除非您计划在未来 25 年内使用 32 位服务器或 PHP 二进制文件，否则我认为这不会成为问题。

PHP 是一种解释型语言，所以当你编写$stamp = 1358425440; 时，它只是 PHP 读入的一串文本，然后会根据 PHP 的方式分配 X 字节的内存来存储它 已编译。因此，如果您将 PHP 二进制文件更新为支持 64 位整数的二进制文件，则无需更改代码。 [至少在理论上。我们都知道 PHP 喜欢改变和弃用常用函数。]

我能看到的唯一考虑是在 PHP 之外存储整数值，即。在 mySQL 中。在这种情况下，您只需确保将时间戳存储为 UNSIGNED INT、BIGINT 或 DATETIME。

SIGNED INT 将于 2038 年 1 月 19 日星期二 03:14:07 GMT 结束，但 UNSIGNED INT 将持续到 2106 年 2 月 7 日星期日 06:28:15 GMT。

【讨论】：

感谢您的解释，我现在使用 PHP 日期函数感觉更舒服了。
感谢您解释 UNSIGNED INT 基本上可以再使用 100 年。我总是让我在 MySQL 中的 INT 无符号——很高兴知道它有一段时间是好的！

【解决方案3】：

改变

 // 32 bit
    int timestampSec

到

 // 64bit
    long timestampSec

用于内部存储。

【讨论】：

看语言标签...你真的不能选择一个。