According to the Javadoc of java.util.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 because the same abbreviation is often used for multiple time zones (for example, “CST” could be U.S. “Central Standard Time” and “China Standard Time”), and the Java platform can then only recognize one of them.
Aside from the ambiguity between timezones, there is inconsistency in the
observance of Daylight Savings Time for the returned time zone, meaning the
TimeZone obtained may not be what you expect. Examples include:
DateTime.getTimeZone("PST") does observe daylight savings time; however,
the identifier implies that it is Pacific Standard Time, i.e. daylight
savings time is not observed.DateTime.getTimeZone("EST") (and "MST" and "HST") do not observe
daylight savings time. However, this is inconsistent with PST (and others),
so you may believe that daylight savings time will be observed.This check will only suggest replacements which yield the same rules as the existing three-letter ID for at least part of the year (e.g. it will suggest “America/Chicago” and “Etc/GMT+6” but not “Asia/Shanghai” as a replacement for “CST”).
Certain 3-letter time zone IDs are not flagged by this check, specifically if
the ID appears in ZoneId.getAvailableZoneIds(), e.g. “UTC”, “GMT”, “PRC”.
Suppress false positives by adding the suppression annotation @SuppressWarnings("ThreeLetterTimeZoneID") to the enclosing element.