We have answer of your question!

100% solved queries, no empty question

Question: Why are 3-letter abbreviations for US timezones inconsistent with respect to daylight savings?


0

I came upon the following curiosity:-

  • TimeZone.getTimeZone considers PST ("Pacific Standard Time") as equivalent to America/Los_Angeles, which observes daylight savings;
  • but it considers MST ("Mountain Standard Time") as equivalent to UTC-7, which does not observe daylight savings.

This can be demonstrated with the following snippet:

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

Output:

true
true

Ideone demo

And we can demonstrate that the timezones obtained using the three-letter abbreviations for the four main US timezones are inconsistent in their use of daylight savings:

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());
}

Output:

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

Aside from the fact that three-letter abbreviations are best avoided anyway (the Javadoc says "However, their use is deprecated..."), this seems very confusing, and a good source of subtle bugs, where you are or aren't expecting daylight savings to be used in multiple time zones.

Is there a reason for this difference in behaviour? Is there subtle property of US timezones which means this behaviour would be expected?

Question author Andy-turner | Source

Answer


1


First to say: We have to understand the difference between time zone identifiers and time zone names. Usually "MST" or "PST stand for (abbreviated) zone names and should be interpreted both as NOT in daylight saving state (suffix ST=Standard-Time).

However, old Java versions have (mis-)used those names also as identifiers, that is, allows to use these strings as parameters to factory methods like TimeZone.getTimeZone(...). This leads us to the question: What is a valid identifier?

The underlying source of the zone data (rules, not names) originates from TZDB which is now maintained by IANA and its actual administrator Paul Eggert. It contains a file named northamerica. Following entry in this file tells us that MST is an identifier but not PST (instead "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

However, Java still uses "PST" as identifier, too - via hardwired old-mappings:

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" }
    };

Just inspect the JDK-file sun.util.calendar.ZoneInfoFile. So "PST" is mapped to America/Los_Angeles. "PST8PDT" is overtaken from TZDB and mapped to a fixed offset. What about "MST"? Here you can set a property how to interprete it, namely the boolean system property "sun.timezone.ids.oldmapping". Its default value is "false". The same mentioned file ZoneInfoFile also contains following switch depending on the value of the system property:

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 has also written an article about this subject. All these oddities are just for backwards compatibility and should be avoided by users.

Answer author Meno-hochschild

Tickanswer.com is providing the only single recommended solution of the question Why are 3-letter abbreviations for US timezones inconsistent with respect to daylight savings? under the categories i.e java , timezone , . Our team of experts filter the best solution for you.

Related Search Queries:


You may also add your answer

Thanks for contributing an answer to Tick Answer!