What three-letter time zone identifiers are not outdated?

Question

In Uncertainty Warning> Javadoc TimeZone :

For compatibility with JDK 1.1.x, some other three-letter time zone identifiers are also supported (such as "PST", "CTT", "AST"). However, their use is outdated ...

It says “different”, but I don’t see where it determines which three-letter identifiers are not outdated. Are they documented anywhere?

GMT is referred to in the document as a reserve, so we can safely assume that one of the non-obsolete identifiers; but:

• Is UTC obsolete? Are you going to use Etc/UTC instead? Or should you use GMT ? ( TimeZone.getTimeZone("UTC").hasSameRules(TimeZone.getTimeZone("GMT") true)

• Is CET (Central European Time) obsolete? If not, what time zone identifier should you use instead? According to this demo , there is only one other identifier giving the same rules as MET (Central European Time).

  There is another timezone identifier, ECT , which has the same display name as CET (Central European Time), but which does not have the same rules (I think they differ somewhere in the mid-1970s) which has those same rules as Europe/Paris . But, since they have different rules, they are not interchangeable.

So, my conclusion from this is that the minimum set of supported three-letter identifiers is GMT and CET ; but it seems strange that is not documented. Any ideas?

---

I note a possible duplicate suggested by @shmosel: Is "GMT" is an abbreviation in Java TimeZone and if so, use it? . This partially covers my question; but I ask a more general question: "What is supported (and how do we know it)", and not just "X is supported."

Answer 1

First, to answer your specific questions:

• All abbreviated identifiers should be considered obsolete. They are insufficient to identify a specific time zone while preserving all the details. For example, you can see all locations that use Central European Time here . Some of them use CET all year round, and some of them use CET in winter, but CEST in summer. Of these, not all of them use the same daylight saving time or have the same time zone offsets throughout their history. There is not enough information in the CET to decide which set of rules to use.

• It is relatively safe to use GMT or UTC , as they are unambiguous. However, it would be more correct to use Etc/GMT or Etc/UTC . If you chose only one, IMHO, it should be Etc/UTC .

• CET should be considered obsolete, along with other abbreviations, as I mentioned. However, it is worth noting that some abbreviations (for example, CET ) come from the TZ database, and some (for example, AST ) come from the Java legacy. This difference is important because only TZDB data is useful in data that can be transmitted elsewhere and interpreted by non-Java based systems.

  It should be noted that the abbreviations US PST and CST NOT in TZDB, although MST and EST .

• Instead of CET you should choose which local time zone applies to your scenario. If you are talking about France, use Europe/Paris . If you are talking about Poland, use Europe/Warsaw etc.

Then understand that the underlying TZ Database has several types of identifiers that are acceptable to use:

• Location based on Area/Locality form

  • Example: America/New_York , Europe/London , Pacific/Honolulu

• Location based on Area/Region/Locality

  • Example: America/Argentina/Buenos_Aires , America/Indiana/Knox

• Administrative zones in the Etc namespace:

  • Example: Etc/UTC , Etc/GMT+2 , Etc/GMT-5
  • +/- based on POSIX standards contrary to the commonly expected ISO standard
  • Commonly used for ships at sea

It also has several forms that are an artifact of history and should NOT be used anymore:

• The location is based on a Country or Country/StateOrRegion

  • Example: US/Pacific , US/Hawaii , Brazil/East , Canada/Newfoundland , Egypt , Cuba

• Continental US POSIX Identifiers:

  • Example: EST5EDT , CST6CDT , MST7MDT , PST8PDT

• Abbreviations - some of them anyway

  • Example: EST , EET , PRC , WET

In addition, Java previously expanded these identifiers to include additional abbreviations that are NOT part of the TZ database. I managed to find them in the list here , as links to their respective modern TZ database identifiers:

 Link Australia/Darwin ACT Link Australia/Sydney AET Link America/Argentina/Buenos_Aires AGT Link Africa/Cairo ART Link America/Anchorage AST Link America/Sao_Paulo BET Link Asia/Dhaka BST Link Africa/Harare CAT Link America/St_Johns CNT Link America/Chicago CST Link Asia/Shanghai CTT Link Africa/Addis_Ababa EAT Link Europe/Paris ECT Link America/New_York EST Link Pacific/Honolulu HST Link America/Indianapolis IET Link Asia/Calcutta IST Link Asia/Tokyo JST Link Pacific/Apia MIT Link America/Denver MST Link Asia/Yerevan NET Link Pacific/Auckland NST Link Asia/Karachi PLT Link America/Phoenix PNT Link America/Puerto_Rico PRT Link America/Los_Angeles PST Link Pacific/Guadalcanal SST Link Asia/Saigon VST 

Of course, these mappings may or may not be self-confident, but they are reportedly used by the TZUpdater Java tool to support support for these legacy Java time zone abbreviations.

Answer 2

Perhaps ZoneId could be used as a link.

 ZoneId.getAvailableZoneIds().stream() .filter(z -> z.length() == 3) .forEach(System.out::println); 

Output

 GMT CET UTC ROK MET PRC WET UCT EET 

If you call ZoneId.of("CST") , it throws

 java.time.zone.ZoneRulesException: Unknown time-zone ID: CST