1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26
|
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".
|