java - 为什么美国时区的 3 个字母缩写与夏令时不一致？

Question

我产生了以下好奇心:-

• TimeZone.getTimeZone 将 PST ( "Pacific Standard Time" ) 视为相当于 America/Los_Angeles，它遵守夏令时；
• 但它认为 MST ( "Mountain Standard Time" ) 相当于 UTC-7，后者不遵守夏令时。

这可以通过以下代码片段进行演示:

System.out.println(
    TimeZone.getTimeZone("MST").hasSameRules(TimeZone.getTimeZone("GMT-7")));
System.out.println(
    TimeZone.getTimeZone("PST").hasSameRules(TimeZone.getTimeZone("America/Los_Angeles")));

输出:

true
true

Ideone demo

我们可以证明，使用美国四个主要时区的三个字母缩写获得的时区在夏令时的使用方面不一致:

for (String id : Arrays.asList("EST", "CST", "MST", "PST")) {
  TimeZone tz = TimeZone.getTimeZone(id);
  System.out.printf("%s is %s; observes DST: %s%n",
      id, tz.getDisplayName(false, TimeZone.LONG), tz.useDaylightTime());
}

输出:

EST is Eastern Standard Time; observes DST: false
CST is Central Standard Time; observes DST: true
MST is Mountain Standard Time; observes DST: false
PST is Pacific Standard Time; observes DST: true

Ideone demo

除了最好避免使用三字母缩写(Javadoc 表示“然而，它们的使用已被弃用......”)这一事实之外，这似乎非常令人困惑，并且是微妙错误的一个很好的来源，您可以在其中是否希望在多个时区使用夏令时。

这种行为差异有原因吗？美国时区是否存在微妙的特性，这意味着这种行为是可以预料的？

Answer 1

首先要说的是:我们必须了解时区标识符和时区名称之间的区别。通常“MST”或“PST 代表(缩写)区域名称，并且应被解释为不处于夏令时状态(后缀 ST=标准时间)。

但是，旧的 Java 版本也(错误)使用这些名称作为标识符，也就是说，允许使用这些字符串作为工厂方法的参数，例如 TimeZone.getTimeZone(...)。这引出了我们的问题:什么是有效标识符？

区域数据的底层来源(规则，而不是名称)源自 TZDB，该数据库现在由 IANA 及其实际管理员 Paul Eggert 维护。它包含一个名为 northamerica 的文件。该文件中的以下条目告诉我们 MST 是一个标识符，但不是 PST(而是“PST8PDT”)。

Zone    EST      -5:00  -   EST
Zone    MST      -7:00  -   MST
Zone    HST     -10:00  -   HST
Zone    EST5EDT      -5:00  US  E%sT
Zone    CST6CDT      -6:00  US  C%sT
Zone    MST7MDT      -7:00  US  M%sT
Zone    PST8PDT      -8:00  US  P%sT

但是，Java 仍然使用“PST”作为标识符 - 通过硬连线旧映射:

private static String[][] oldMappings =
    {
        { "ACT", "Australia/Darwin" },
        { "AET", "Australia/Sydney" },
        { "AGT", "America/Argentina/Buenos_Aires" },
        { "ART", "Africa/Cairo" },
        { "AST", "America/Anchorage" },
        { "BET", "America/Sao_Paulo" },
        { "BST", "Asia/Dhaka" },
        { "CAT", "Africa/Harare" },
        { "CNT", "America/St_Johns" },
        { "CST", "America/Chicago" },
        { "CTT", "Asia/Shanghai" },
        { "EAT", "Africa/Addis_Ababa" },
        { "ECT", "Europe/Paris" },
        { "IET", "America/Indiana/Indianapolis" },
        { "IST", "Asia/Kolkata" },
        { "JST", "Asia/Tokyo" },
        { "MIT", "Pacific/Apia" },
        { "NET", "Asia/Yerevan" },
        { "NST", "Pacific/Auckland" },
        { "PLT", "Asia/Karachi" },
        { "PNT", "America/Phoenix" },
        { "PRT", "America/Puerto_Rico" },
        { "PST", "America/Los_Angeles" },
        { "SST", "Pacific/Guadalcanal" },
        { "VST", "Asia/Ho_Chi_Minh" }
    };

只需检查 JDK 文件 sun.util.calendar.ZoneInfoFile 。因此“PST”被映射到 America/Los_Angeles。 “PST8PDT”被 TZDB 取代并映射到固定偏移。 “MST”怎么样？在这里您可以设置一个属性如何解释它，即 boolean 系统属性“sun.timezone.ids.oldmapping”。它的默认值为“假”。提到的相同文件 ZoneInfoFile 还包含以下开关，具体取决于系统属性的值:

private static void addOldMapping() {
      for (String[] arrayOfString1 : oldMappings) {
        aliases.put(arrayOfString1[0], arrayOfString1[1]);
      }
      if (USE_OLDMAPPING) {
        aliases.put("EST", "America/New_York");
        aliases.put("MST", "America/Denver");
        aliases.put("HST", "Pacific/Honolulu");
      } else {
        zones.put("EST", new ZoneInfo("EST", -18000000));
        zones.put("MST", new ZoneInfo("MST", -25200000));
        zones.put("HST", new ZoneInfo("HST", -36000000));
      }
}

IBM 还写了 an article关于这个话题。所有这些奇怪的现象只是为了向后兼容，用户应该避免。