Mysql 美国/洛杉矶、美国/太平洋和PST8PDT时区之间的差异？

我需要将MySQL数据库中的一组日期从太平洋时间（美国/洛杉矶）转换为UTC。我找到了一个解决方法

在我的测试和准备过程中，我发现当使用以下任何时区名称时，我得到了相同的时间转换：

• 美国/洛杉矶
• 美国/太平洋
• PST8PDT

因此，我的问题如下：

• 这些都是同一事物的别名吗？或者在某个时间点，它们之间是否存在实际差异
• 如果我想在网站上向用户提供时区列表，最好让他们从

  美国

  名称组中选择，还是从

  美国

  名称组中选择

---

US/Pacific和PST8PDT都属于，并附带以下警告：

请不要使用此处列出的任何时区（UTC除外），它们的存在只是出于向后兼容的原因。

它们都应指向同一时区，比较：

---

因此，您应该使用America/Los_Angeles，顺便说一句，这对于用户来说应该是一个非常“自然”且容易选择的东西。

US/Pacific

是IANA数据库中指向

America/Los_Angeles

的“链接”（请参阅）。在我见过的Linux系统上，前者是后者的硬链接文件；在OSX上，它可能是一个副本。如果对

/usr/share/zoneinfo/

中的条目运行校验和（例如md5或sha1），则2应该匹配

然而，

PST8PDT

可能会有所不同——我还没有弄清楚具体的方法。表示它不跟踪夏令时更改的历史记录，即它只是将当前DST规则追溯应用到过去；但在这个ruby示例中，情况似乎并非如此。如果追溯适用当前规则，则两者都是

-0700

：

> ENV['TZ']='PST8PDT'
> [Time.mktime(2006, 4, 2, 1, 59, 59), Time.mktime(2006, 4, 2, 2)]
=> [2006-04-02 01:59:59 -0800, 2006-04-02 03:00:00 -0700] 

上面有一段原始数据库维护者的话。消息作者解释说，包括

PST8PDT

在内的传统区域过去有过时的信息，但现在无论这意味着什么，“不那么不正确”

---

总而言之，不要使用

PST8PDT

，但使用

US/Pacific

或

America/Los_Angeles

，

美国/东部

，

美洲/纽约

和

EST5EDT

都应该是安全的。这是我发现的

对于《1966年统一时间法案》于1967年生效后的日期，这些时区都是相同的。此外，美国在世界大战期间执行标准DST规则，因此它们在1918-1919年和1942-1945年期间都是相同的

对于1918年之前、1920年至1941年之间以及1946年至1966年之间的任何日期，

EST5EDT

始终与

EST

相同<代码>PST8PDT将始终与PST相同

1967年之前，

美洲/纽约

将提供纽约市观测到的时间。因此，夏令时将遵循纽约市或纽约州政府制定的规则。1883年11月18日12:03:58之前的任何日期将采用当地平均时间，与UTC的偏移量为-4:56:02。对于

美洲/洛杉矶

而言，1883年11月18日12:07:02之前的任何时间都将是当地平均时间，与

UTC

的偏移量为-7:52:58。1883年至1967年间，洛杉矶遵循洛杉矶和加利福尼亚州的夏时制规则

如果您有多个系统，其中一个假设为

PST8PDT

，另一个假设为

Americas/Los_Angeles

，则可能会发生奇怪的事情。对于最近的任何东西，数据看起来都很好。例如，从1966年夏天开始的生日可能会被移动一个小时，然后被截断，因此看起来是在前一天

---

如果你在处理阿拉斯加的旧日约会，你需要记住阿拉斯加是从俄罗斯买来的，这只是为了增加乐趣。1867年10月18日之前的日期位于国际日期线的另一侧，使用儒略历，而不是公历。例如，朱诺从1867年10月6日（朱利安）+15:02:19走到1867年10月18日（格里高利）-8:57:41。

谢谢，这正是我所想的，但很高兴得到确认。当我读到“其他”时区时，我不得不大笑。。。有点像“其他”的白肉：）只是出于好奇，“国家/城市”时区是否是目前事实上的标准？我用过美国/东部和美国/纽约；甚至有几次后者不可用，但那是很久以前的事了。@我相信现在城市应该成为标准。在美国，这可能没有多大区别，但在世界上的一些地方，日光节约法规和其他法规可能没有被旧的、通用的时区充分涵盖。为什么“其他”时区文件来自美国？还有其他更原始的资源吗？