为啥 PHP 和 MySQL 的 unix 时间戳在 1983 年 10 月 29 日不同？

Posted 2023-02-24

【中文标题】为啥 PHP 和 MySQL 的 unix 时间戳在 1983 年 10 月 29 日不同？

【英文标题】：Why do PHP and MySQL unix timestamps diverge on 1983-10-29?为什么 PHP 和 MySQL 的 unix 时间戳在 1983 年 10 月 29 日不同？

【发布时间】：2011-09-07 03:04:21

【问题描述】：

我一直在我的应用程序中使用 php 的 strtotime 和 mysql 的 UNIX_TIMESTAMP 函数，将日期转换为时间戳。 PHP 和 MySQL 在我的本地机器上运行，这些函数通常返回相同的结果，正如我所期望的那样：

$ php
<?php echo strtotime("2011-06-02"); ?>
1307001600

mysql> SELECT UNIX_TIMESTAMP("2011-06-02") ts;
+------------+
| ts         |
+------------+
| 1307001600 |
+------------+

但是，我碰巧注意到，当我输入1983-01-01 作为日期时，结果不再相等：

$ php
<?php echo strtotime("1983-01-01"); ?>
410263200

mysql> SELECT UNIX_TIMESTAMP("1983-01-01") ts;
+-----------+
| ts        |
+-----------+
| 410256000 |
+-----------+

如您所见，PHP 返回 410263200，而 MySQL 返回 410256000 - 相差 7200 秒。

这让我很好奇，我想知道时间戳在哪一天不再等价，所以我写了一个小程序，从今天的日期开始（以 Ymd 格式），使用 PHP 的 strtotime 和 MySQL 的 UNIX_TIMESTAMP并比较结果。然后它从每个值中减去 1 天并循环，直到它们不再相等。

结果：

1983-10-29

1983 年 10 月 29 日，出于某种原因，strtotime 和 UNIX_TIMESTAMP 返回的值相差 7200 秒。

有什么想法吗？

感谢阅读。

【问题讨论】：

你在哪个时区？ （date_default_timezone_get()）？想知道这是否是特定于时区的一些奇怪的日历变化——大概发生在 1983 年 10 月 30 日。

两个小时，世界停止了，所以我们都可以在新发布的“亚当”上玩我们的 ColecoVision 游戏

【参考方案1】：

你说你是在阿拉斯加时间。来自http://www.statoids.com/tus.html：

1983-10-30 02:00：除阿留申群岛和圣劳伦斯岛外，阿拉斯加的所有地区都切换到 AT。在改变之前，阿拉斯加以西 138°（朱诺）以东一直在 PT 上； 138°W 和 141°W（Yakutat）之间的时间是育空时间，即 UTC-9 和 DST； 162°W（Nome）以西一直在白令时间，这是 UTC-11 与 DST。阿拉斯加-夏威夷区域名称更改为夏威夷-阿留申。

所以，我猜这是因为您的时区在 1983 年 10 月 30 日改变了两个小时（7200 秒 = 2 小时）。

我猜 MySQL 的 UNIX_TIMESTAMP 使用的时区与 PHP 中的阿拉斯加设置不同，这可能是服务器默认设置，也可能取决于您的连接设置，因此当您到达该日期时，它们会出现差异。

您可以通过询问 MySQL 在与SELECT @@global.time_zone, @@session.time_zone; 的连接上的时区设置是什么来收集更多信息；请参阅this answer 了解有关输出的更多信息以及如何解释它。

【讨论】：

不错的发现...所以报告准确。

也是一个不错的read 特别是因为它记录了在 1883 年（100 年前）为美国设定了时区，除了阿拉斯加，因为它没有铁路。

是的。我猜 MySQL 的 UNIX_TIMESTAMP 使用的是不同的时区，这可能是服务器默认时区，或者取决于您的连接设置，因此当您到达转换日期时，这与 PHP 的阿拉斯加时区不同。

@echo 不用担心 :) 好问题！

MySQL 为这两个值返回 SYSTEM，PHP 报告 US/Alaska。日期和时间首选项 (OSX) 表示 AKDT。