Which three-letter time zone IDs are not deprecated?

Question

There is a deprecation warning in the Javadoc of TimeZone:

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

It says "other" here, but I can't see where it defines which three-letter IDs are non-deprecated. Are these documented anywhere?

GMT is mentioned in the doc as the fallback, so it's safe to assume that's one of non-deprecated IDs; but:

• Is UTC deprecated? Are you meant to use Etc/UTC instead? Or should you be using GMT? (TimeZone.getTimeZone("UTC").hasSameRules(TimeZone.getTimeZone("GMT") is true)

• Is CET (Central European Time) deprecated? If not, what time zone identifier are you supposed to use instead? According to this demo, there is only one other identifier yielding the same rules, which is MET (Middle European Time).

  There is another timezone ID, ECT, which has the same display name as CET (Central European Time), but which doesn't have the same rules (I think they differ somewhere in the mid 1970s), which has the same rules as Europe/Paris. But, since they have different rules, the two are not interchangable.

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

---

I note the possible duplicate suggested by @shmosel: Is "GMT" an Abbreviation in Java TimeZone and if So is it OK to use it?. That partly covers my question; but I'm asking the more general question "what is supported (and how do we know that)", rather than just "is X supported".

Answer 1

First, to answer your specific questions:

1. All abbreviation-based identifiers should be considered deprecated. They are not sufficient to identify a particular time zone with all detail retained. For example, you can see all the locations that use Central European Time here. Some of them use CET all year long, and some of them use CET in the winter but CEST in the summer. Of those, not all of them use the same DST transition days, or have the same time zone offsets throughout their history. There's just not enough information in CET to decide which set of rules to use.

2. It is relatively safe to use GMT or UTC, as these are unambiguous. However it would be more correct to use Etc/GMT or Etc/UTC. If you were to pick just one, IMHO it should be Etc/UTC.

3. CET should be considered deprecated, along with other abbreviations, as I mentioned. However, it's worth noting that some abbreviations (like CET) come from the TZ Database, and some (like AST) come from legacy of Java. This distinction is important, as only the TZDB ones are useful in data that may be transmitted elsewhere and interpreted by non-Java based systems.

   Of particular note, recognize that the US abbreviations PST and CST are NOT in the TZDB, even though MST and EST are.

4. Instead of CET, you should pick which locality-based time zone is relevant to your scenario. If you are talking about France, use Europe/Paris. If you are talking about Poland, use Europe/Warsaw, etc.

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

• Location based, in the form of Area/Locality

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

• Location based, in the form of Area/Region/Locality

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

• Administrative zones, in the Etc namespace:

  • Ex: Etc/UTC, Etc/GMT+2, Etc/GMT-5
  • +/- are based on POSIX standards, opposite of the typically 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 any more:

• Location based, in the form of Country or Country/StateOrRegion

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

• POSIX identifiers in the continental US:

  • Ex: EST5EDT, CST6CDT, MST7MDT, PST8PDT

• Abbreviations - some of them anyway

  • Ex: EST, EET, PRC, WET

Additionally, Java had previously extended these identifiers to include additional abbreviations that are NOT part of the TZ Database. I was able to find them listed here, as links to their corresponding TZ Database modern 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 opinionated - but they are reportedly the ones used by Java's TZUpdater tool to carry forward support for these legacy Java time zone abbreviations.

Answer 2

Maybe ZoneId could be used as reference.

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