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