我需要将MySQL数据库中的一堆日期从太平洋时间（America / Los_Angeles）转换为UTC。我找到了great SO answer如何做到这一点。
在我的测试和准备期间，我发现在使用以下任何时区名称时，我获得的转换时间相同：
所以我的问题如下：
America组名称或US组名称中选择它们吗？答案 0 :(得分：23)
US / Pacific和PST8PDT都属于"other" timezones，它带有此警告：
请不要使用此处列出的任何时区（除了UTC），它们仅出于向后兼容的原因而存在。
他们都应该引用相同的时区，比较：
http://www.travelmath.com/time-zone/PST8PDT
http://www.travelmath.com/time-zone/US/Pacific
http://www.travelmath.com/time-zone/America/Los_Angeles
因此，您应该使用America / Los_Angeles，顺便说一下，这也应该是一个非常“自然”且容易为用户选择的东西。
答案 1 :(得分：6)
US/Pacific是IANA数据库中America/Los_Angeles的“链接”（请参阅wikipedia）。在我看过的Linux系统上，前者是后者的硬链接文件;在OS X上它可能是一个副本。如果您对/usr/share/zoneinfo/中的条目运行校验和（例如md5或sha1），则2应该匹配。
然而，PST8PDT可能会有所不同 - 我还没弄清楚到底是怎么回事。 This bug report表示它不跟踪夏令时变化的历史记录，即它只是追溯性地将当前的DST规则应用于过去;但在这个红宝石例子中似乎并非如此。如果它追溯应用当前规则，则两者都是-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]
在this message上有来自原始数据库维护者的引用。消息作者解释说，包括PST8PDT在内的遗留区域曾经有过时的信息，但现在无论这意味着什么都“不正确”。
总而言之，请勿使用PST8PDT，但使用US/Pacific或America/Los_Angeles应该是安全的。
答案 2 :(得分：6)
我遇到了并行US/Eastern，Americas/New_York和EST5EDT的问题。这是我发现的。
1967年统一时间法于1967年生效后的日期，这些时区都是相同的。美国也在世界大战期间执行了标准的夏令时规则，因此它们在1918-1919和1942-1945都是相同的。
对于1918年之前，1920年至1941年之间以及1946年至1966年之间的任何日期，EST5EDT将始终与EST相同。 PST5PDT将始终与PST相同。
在1967年之前，Americas/New_York将在纽约市提供观察的时间。因此，夏令时将遵循纽约市政府或纽约州政府制定的规则。 1883年11月18日12:03:58之前的任何日期都将在当地平均时间，与UTC的偏差为-4：56：02。对于Americas/Los_Angeles，在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。