MySQL 2038 年易受攻击

Question

我正在学习 Drupal 并问了这个问题：

https://drupal.stackexchange.com/questions/45443/why-timestamp-format-was-chosen-for-users-created-field/45446#45446

我决定检查一下，在 Unix 时代结束后 CMS 将如何表现。将我的本地日期设置为 01.01.2040 并重新启动。

令我惊讶的是，该网站根本不起作用。原因是，MySQL 宕机了。我尝试手动连接并出现错误：

>mysql -uroot -ppass
ERROR 2003 (HY000): Can't connect to MySQL server on 'localhost' (10061)

我在 Win XP 上使用 MySQL 5.5。为什么会有这种奇怪的行为？

Answer 1

基本原理可能是基于哪种日期时间表示对于 MySQL 和操作系统（在本例中为 Windows XP）更容易处理

\n\n

\n
• DATETIME占用8个字节
\n
• TIMESTAMP占用4个字节
\n

\n\n

他们的数据和时间范围会有很大差异。请注意 MySQL 文档中的更多差异

\n\n

\n

DATETIME 类型用于包含日期和时间部分的值。\n MySQL 以“YYYY-MM-DD\n HH:MM:SS”格式检索并显示 DATETIME 值。支持的范围是“1000-01-01 00:00:00”到\n“9999-12-31 23:59:59”。

\n\n

TIMESTAMP 数据类型用于包含日期和时间部分的值。\n TIMESTAMP 的范围为 '1970-01-01 00:00:01' UTC 到\n '2038-01-19 03:14:07' UTC。

\n\n

MySQL 将 TIMESTAMP 值从当前时区转换为 UTC 进行存储，然后从 UTC 转换回当前时区进行检索。（对于 DATETIME 等其他类型，不会发生这种情况。）默认情况下，\n每个连接的时区是服务器的时间。时区可以针对每个连接进行设置。只要时区设置保持不变，您就会返回与存储的值相同的值。如果您存储 TIMESTAMP 值，然后更改时区并检索该值，则检索到的值与您存储的值\n。出现这种情况是因为双向转换未使用相同的时区。\n 当前时区可作为 time_zone 系统变量的值使用。有关详细信息，请参阅\n 第 10.6 节，\xe2\x80\x9cMySQL 服务器时区支持\xe2\x80\x9d。

\n

\n\n

由于 MySQL 和 Windows 都有 TimeZone 支持，因此让 mysqld 更多地了解 Windows 可能符合 MySQL 的最佳利益。这可能是让您的 MySQL 数据库从 Windows 迁移到 Linux 的秘密动机。（我的阴谋论）

\n