小编典典

PHP和mySQL:2038年Bug:这是什么?怎么解决呢?

mysql

我当时在考虑使用TIMESTAMP存储日期和时间,但是我读到它有2038年的限制。与其大量提出问题,不如将其分解成小部分,以便新手用户也易于理解。所以我的问题是:

  1. 2038年的问题到底是什么?
  2. 为什么会发生?发生时会发生什么?
  3. 我们该如何解决?
  4. 是否有使用它的其他可能的选择,而不会引起类似的问题?
  5. 当使用TIMESTAMP的现有应用程序真正发生时,我们该怎么办?

提前致谢。


阅读 1009

收藏
2020-05-17

共1个答案

小编典典

我已将其标记为社区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`

资源资源

2020-05-17