我正在考虑使用 TIMESTAMP 来存储日期+时间,但我读到它有 2038 年的限制。我不喜欢批量提出问题,而是更愿意将其分成小部分,以便新手用户也很容易理解。所以我的问题是:
- 2038年问题到底是什么?
- 为什么会发生以及发生时会发生什么?
- 我们该如何解决呢?
- 是否有任何可能的替代方案可以使用它,而不会造成类似的问题?
- 当问题真正发生时,我们可以对使用 TIMESTAMP 的现有应用程序做些什么来避免所谓的问题?
我已将其标记为社区 wiki,因此您可以在闲暇时随意编辑。
2038年问题到底是什么?
“2038 年问题(也称为 Unix Millennium Bug,Y2K38,类似于 Y2K 问题)可能会导致某些计算机软件在 2038 年之前或之内出现故障。该问题会影响所有将系统时间存储为带符号的 32 位时间的软件和系统。位整数,并将该数字解释为自 1970 年 1 月 1 日 00:00:00 UTC 以来的秒数。”
为什么会发生以及发生时会发生什么?
超越时代2038 年 1 月 19 日星期二 03:14:07 UTC将“环绕”并在内部存储为负数,这些系统会将其解释为 1901 年 12 月 13 日而不是 2038 年的时间。这是因为自 UNIX 纪元(1 月 1 日)以来的秒数1970 00:00:00 GMT)将超过计算机 32 位有符号整数的最大值。
我们该如何解决呢?
- 使用长数据类型(64 位就足够了)
- 对于 MySQL(或 MariaDB),如果您不需要时间信息,请考虑使用
DATE
列类型。如果您需要更高的精度,请使用DATETIME
而不是TIMESTAMP
。当心DATETIME
列不存储有关时区的信息,因此您的应用程序必须知道使用了哪个时区。
- 维基百科上描述的其他可能的解决方案 http://en.wikipedia.org/wiki/Year_2038_problem#Solutions
- 将您的 Mysql 升级到8.0.28 https://dev.mysql.com/doc/relnotes/mysql/8.0/en/news-8-0-28.html#mysqld-8-0-28-feature或更高
是否有任何可能的替代方案可以使用它,而不会造成类似的问题?
尽可能尝试使用大类型在数据库中存储日期:64 位就足够了 - GNU C 和 POSIX/SuS 中的 long long 类型,或者sprintf('%u'...)
在 PHP 或 BCmath 扩展中。
尽管我们还没有到 2038 年,但有哪些潜在的破坏性用例?
那么一个MySQLDATETIME http://dev.mysql.com/doc/refman/5.6/en/datetime.htmlTIMESTAMP 的范围是 1000-9999,而 TIMESTAMP 的范围是 1970-2038。如果您的系统存储生日、未来的远期日期(例如 30 年抵押贷款)或类似信息,那么您已经会遇到此错误。再次强调,如果这会成为问题,请不要使用 TIMESTAMP。
当问题真正发生时,我们可以对使用 TIMESTAMP 的现有应用程序做些什么来避免所谓的问题?
到 2038 年,几乎没有 PHP 应用程序仍然存在,尽管很难预见,因为 Web 还很难成为一个遗留平台。
这是更改数据库表列以进行转换的过程TIMESTAMP
to 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 年问题(维基百科) http://en.wikipedia.org/wiki/Year_2038_problem
- 互联网将在 30 年内终结 http://readwrite.com/2008/03/13/the_internet_will_end_in_30_years/
本文内容由网友自发贡献,版权归原作者所有,本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容,请联系:hwhale#tublm.com(使用前将#替换为@)