我已将其标记为社区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 fieldALTER TABLE `myTable` CHANGE `myTimestamp` `temp_myTimestamp` int(11) NOT NULL;# create a new DATETIME column of the same name as your old columnALTER TABLE `myTable` ADD `myTimestamp` DATETIME NOT NULL;# update all rows by populating your new DATETIME fieldUPDATE `myTable` SET `myTimestamp` = FROM_UNIXTIME(temp_myTimestamp);# remove the temporary columnALTER TABLE `myTable` DROP `temp_myTimestamp`
资源资源
- 2038年问题（维基百科）
- 互联网将在30年后终结
