我已将其标记为社区Wiki，因此随时可以编辑。

2038年的问题到底是什么？

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

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

超越时代 3时14分07秒UTC在星期二，2038 1月19日
将“环绕”并为负数，这些系统将在1901年12月13日，解释为一个时间，而不是在2038年内部存储这是由于自UNIX时代（1970年1月1日00:00:00
GMT）以来的秒数将超过计算机的32位带符号整数的最大值的事实。

我们该如何解决？

• 使用长数据类型（64位足够）
• 对于MySQL（或MariaDB），如果不需要时间信息，请考虑使用DATE列类型。如果需要更高的精度，请使用DATETIME而不是TIMESTAMP。请注意，DATETIME列不存储有关时区的信息，因此您的应用程序将必须知道使用了哪个时区。
• 维基百科上描述的其他可能的解决方案
• 等待MySQL开发人员修复十年前报告的错误。

是否有使用它的其他可能的选择，而不会引起类似的问题？

尝试使用大类型在数据库中存储日期：64位就足够了-GNU C和POSIX /
SuS或sprintf('%u'...)PHP或BCmath扩展名中的long long类型。

即使我们尚未到2038年，仍有哪些潜在的突破性用例？

因此，MySQL
DATETIME的范围为1000-9999，而TIMESTAMP的范围仅为1970-2038。如果您的系统存储了出生日期，将来的远期日期（例如30年的抵押贷款）或类似的日期，那么您已经遇到了这个错误。同样，如果这将成为问题，请不要使用TIMESTAMP。

当使用TIMESTAMP的现有应用程序真正发生时，我们该怎么办？

在2038年，仍然很少有PHP应用程序出现，尽管人们很难预见到Web仍不是旧平台。

这是更改数据库表列以转换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`

资源资源

• 2038年问题（维基百科）
• 互联网将在30年后终结