PHP & mySQL : Year 2038 Bug: What is it? 如何解决？

Question

我正在考虑使用 TIMESTAMP 来存储日期+时间，但我读到它有 2038 年的限制。与其大量提出我的问题，我更愿意将其分解成小部分，以便新手用户也易于理解。所以我的问题:

1. 2038 年问题到底是什么？
2. 为什么会发生，发生时会发生什么？
3. 我们如何解决？
4. 是否有任何可能的替代方法来使用它，并且不会造成类似的问题？
5. 我们可以对使用 TIMESTAMP 的现有应用程序做些什么，以避免所谓的问题真正发生时？

提前致谢。

Answer 1

我已将此标记为社区 wiki，因此您可以随意编辑。

2038 年问题到底是什么？

“2038 年问题(也称为 Unix Millennium Bug，类似于 Y2K 问题的 Y2K38)可能会导致某些计算机软件在 2038 年之前或之后发生故障。该问题会影响所有将系统时间存储为一个带符号的 32 位整数，并将此数字解释为自 1970 年 1 月 1 日 00:00:00 UTC 以来的秒数。”

---

为什么会发生，发生时会发生什么？

2038 年 1 月 19 日星期二 03:14:07 UTC 之后的时间将“环绕”并在内部存储为负数，这些系统会将其解释为 12 月 13 日的时间， 1901 年而不是 2038 年。这是因为自 UNIX 纪元(格林威治标准时间 1970 年 1 月 1 日 00:00:00 GMT)以来的秒数将超过计算机 32 位有符号整数的最大值。

---

我们如何解决？

• 使用长数据类型(64 位就足够了)
• 对于 MySQL(或 MariaDB)，如果您不需要时间信息，请考虑使用 DATE 列类型。如果您需要更高的准确度，请使用 DATETIME 而不是 TIMESTAMP。请注意，DATETIME 列不存储有关时区的信息，因此您的应用程序必须知道使用了哪个时区。
• Other Possible solutions described on Wikipedia
• 升级你的Mysql到8.0.28或更高

---

是否有任何可能的替代方法来使用它，并且不会造成类似的问题？

尽可能使用大类型在数据库中存储日期:64 位就足够了 - 在 GNU C 和 POSIX/SuS 中使用 long long 类型，或者 sprintf('%u'...) 在 PHP 或 BCmath 扩展中。

---

尽管我们还没有到 2038 年，但有哪些潜在的破坏性用例？

所以一个 MySQL DATETIME范围是 1000-9999，但 TIMESTAMP 的范围只有 1970-2038。如果您的系统存储了生日、 future 的远期日期(例如 30 年的抵押贷款)或类似的，那么您已经遇到了这个错误。同样，如果这会成为问题，请不要使用 TIMESTAMP。

---

我们可以对现有的使用 TIMESTAMP 的应用程序做些什么来避免所谓的问题，当它真正发生时？

很少有 PHP 应用程序会在 2038 年出现，尽管很难预见，因为网络还不是一个遗留平台。

这是一个更改数据库表列以将 TIMESTAMP 转换为 DATETIME 的过程。首先创建一个临时列:

# rename the old TIMESTAMP field
ALTER TABLE `myTable` CHANGE `myTimestamp` `temp_myTimestamp` int(11) NOT NULL;

# create a new DATETIME column of the same name as your old column
ALTER TABLE `myTable` ADD `myTimestamp` DATETIME NOT NULL;

# update all rows by populating your new DATETIME field
UPDATE `myTable` SET `myTimestamp` = FROM_UNIXTIME(temp_myTimestamp);

# remove the temporary column
ALTER TABLE `myTable` DROP `temp_myTimestamp`

---

资源

• Year 2038 Problem (Wikipedia)
• The Internet Will End in 30 Years