JDK-6214500 : (tz) Need method for retrieving only the non-deprecated time zones
  • Type: Enhancement
  • Component: core-libs
  • Sub-Component: java.util:i18n
  • Affected Version: 1.4.2
  • Priority: P4
  • Status: Resolved
  • Resolution: Won't Fix
  • OS: linux
  • CPU: x86
  • Submitted: 2005-01-06
  • Updated: 2023-07-18
  • Resolved: 2023-07-18
Related Reports
Relates :  
Description
A DESCRIPTION OF THE REQUEST :
Apologies if this is a duplicate - I  tried to search for a report of this nature, but did not find one.

The documentation for the java.util.TimeZone class in 1.4.x states the following, in regard to the old 1.1.x three-letter time zones:

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.

It would appear that there are also other time zones that , while not three-letter time zones, nevertheless they are also of the old format (eg, the time zone "Japan"). If this is the case, then perhaps the documentation for TimeZone needs to be updated as well to reflect this.

The problem is that the two TimeZone.getAvailableIDs() methods return all the available time zones - including those that are deprecated. There is no means for the developer to tell which ones are deprecated.

JUSTIFICATION :
If time zones are deprecated, then good development practice should dictate that they not be used in new code. However, without this enhancement, developers have no reliable way of ensuring that they avoid using deprecated time zones.

Not only is it bad programming practice to use deprecated time zones, it also looks strange to the user if we present them with a list of time zone IDs to choose from and some of them are of a different format. It makes the finished product look unpolished.

As noted below, a workaround is available - however, the problem is that this workaround is based on an assumption I have made based on inspection, and this assumption is not part of the documented behaviour of the class. Thus, there is the risk that the behaviour on which my workaround is based may change in a future release and break the workaround.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Better documentation on which time zones are deprecated would be a start. However, this will not be forwards compatible. For that, API changes will be necessary. I suggest one or both of the following, but you might be able to come up with a better idea:

-Addition of an instance-level method "isDeprecated()" to class "TimeZone" - with the default implementation returning false. This can be overridden in implementation classes to return the appropriate value. Alternatively, a static "isDeprecated(String)" method on this class which takes a time zone ID as its parameter.

-Addition of an equivalent of "getAvailableIDs()" to return only the time zone IDs for time zones that aren't deprecated - possibly deprecating "getAvailableIDs()". Alternatively, change the functionality of "getAvailableIDs()" to only return non-deprecated time zones, and add a new method (again, possibly deprecated) to return all IDs (including for deprecated time zones).
ACTUAL -
TimeZone.getAvailableIDs() returns all time zones - up-to-date or deprecated - and TimeZone instances have no means of identifying if they are deprecated.

CUSTOMER SUBMITTED WORKAROUND :
I managed to deduce by inspection that the up-to-date time zones are the ones with a '/' character in their ID. They are all of the form '<continent>/<city>' (or 'Etc/<special>'). Thus, prior to displaying the list, I create a new array or List of the available time zones, but filtering out any time zone that does not include a '/' character. This gives me a list of time zones that are all of the same format.
###@###.### 2005-1-06 00:27:25 GMT

Comments
There are currently no plans on introducing a method with the sole purpose of distinguishing if a timezone ID is deprecated or not. Instead, the specification for TimeZone was updated to explicitly link to all of the deprecated 3-letter JDK IDs. That was resolved in -> JDK-8311968
18-07-2023

WORK AROUND The following is the JDK 1.1.x compatible time zone IDs. (The file is found in the J2SE source tree as make/sun/javazic/tzdata_jdk/jdk11_backward.) Note that MET was changed to follow the Olson public zone info as of J2SE 1.4.0, and GMT isn't deprecated. ---- # # @(#)jdk11_backward 1.4 04/08/12 # # JDK 1.1.x compatible time zone IDs # 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 Link GMT UTC ---- ###@###.### 2005-1-06 04:49:27 GMT
06-01-2005

EVALUATION I put the list of the JDK 1.1.x compatible time zone IDs in Work Around. Please note that the Olson public zone info itself has compatibility names, including 3-letter ones such as PRC. ###@###.### 2005-1-06 04:49:27 GMT
06-01-2005