PHP&MySQL：2038年Bug：是什么？如何解决？

Question

PHP&MySQL：2038年Bug：是什么？如何解决？我想用时间戳来存储日期+时间，但我读到它有一个2038年的限制。与其大量地问我的问题，我更喜欢把它分成几个小部分，这样新手用户也很容易理解。所以我的问题是：2038年到底是什么问题？它为什么会发生，当它发生时会发生什么？我们怎么解决这个问题？除了使用它之外，是否还有其他可能的替代办法，而这并不构成类似的问题？当时间戳真正发生时，我们能对使用时间戳的现有应用程序做些什么来避免所谓的问题呢？提前谢谢。

Answer 1

当使用UNIX时间戳存储日期时，实际上使用的是32位整数，这将保持自1970-01-01以来的秒数；请参见Unix时间

该32位数将在2038年溢出。这就是2038年的问题。

要解决这个问题，您不能使用32位UNIX时间戳来存储日期-这意味着，在使用MySQL时，不应该使用TIMESTAMP，但是DATETIME(见10.3.1.日期时间、日期和时间戳类型。) :

这个DATETIME当您需要同时包含日期和时间信息的值时，将使用类型。支持范围是'1000-01-01 00:00:00'到'9999-12-31 23:59:59'.

这个TIMESTAMP数据类型的范围为'1970-01-01 00:00:01'世界协调时'2038-01-19 03:14:07'世界协调时。

这个(可能)为了避免/解决这个问题，您可以对应用程序做的最好的事情就是不要使用TIMESTAMP，但是DATETIME对于必须包含1970年至2038年之间的日期的列。

不过，有一个小提示：很可能有很高的可能性。(统计数字)在2038^之前，您的应用程序将被重写好几次，所以，如果您以后不必处理日期，您将不必处理当前版本的应用程序的问题.

Answer 2

在谷歌上进行快速搜索就可以做到这一点：2038年问题

1. 2038年的问题(又称Unix千年Bug，Y2K38，类比于Y2K问题)可能导致一些计算机软件在2038年之前或在2038年出现故障。
2. 此问题影响到所有将系统时间存储为带符号32位整数的软件和系统，并将此数字解释为自1970年1月1日协调世界时00：00：00以来的秒数。最近可以用这种方式表示的时间是2038年1月19日星期二的协调世界时03：14：07。超过这一刻的时间将被“包围”，并作为负数存储在内部，这些系统将把这个数字解释为1901年的日期，而不是2038年的日期。
3. 对于现有的cpu/OS组合、现有的文件系统或现有的二进制数据格式，这个问题没有简单的解决方法。