JDK-6274985 : TimeZone.getDisplayName() should not rely on DateFormatSymbols.getZoneStrings()
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.util:i18n
  • Affected Version: 6
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2005-05-24
  • Updated: 2011-02-16
  • Resolved: 2005-08-15
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 6
6 b48Fixed
Related Reports
Relates :  
JDK-6304305 - performance: regression: parsing time zone fields is slow in SimpleDateFormat
Description
The TimeZoneNameProvider getDisplayName(...) is receiving locales that are only provided by the JRE.  In my TimeZoneNameProvider implementation, I return a localized string when a call is made to getDisplayName(...) for locales en_US, en_US_XX and aa_BB in.  When a call to getDisplayName(...) is made from my TimeZoneNameProviderTest for these locales, only the localized string for en_US_XX and aa_BB should be returned.  However, getDisplayName(...) is only receiving a call with the locale being en_US, instead of en_US_XX and aa_BB. 

The nightly build that I used for running my tests is 2005-05-23.mustang/solaris-sparc.  Attached is a copy of my pluggable locale tests(pluggableLocalesTest.tar).  It is very easy to setup.  Just untar it and follow the README.   

Please see the following files:
src/pluggablelocales/lib/pseudolocales/TimeZoneNameProviderImpl.java
src/pluggablelocales/lib/tests/TimeZoneNameProviderTest.java
src/pluggablelocales/pseudolocales/pseudolocales1/...TimeZoneNameProviderImpl1.java
src/pluggablelocales/tests/TimeZoneNameProviderTest1.java

###@###.### 2005-05-24 03:29:53 GMT
Comments
EVALUATION The current TimeZone.getDisplayName implementation relies on DateFormatSymbols.getZoneStrings() method. The problem itself is caused by the test case error, where it creates its custom DateFormatSymbols object (DateFormatSymbolsProviderImpl.getInstance(Locale)) in the default locale, regardless of the given locale, such as en_US_XX or aa_BB. This results in querying the time zone names in en_US locale. However, TimeZone.getDisplayName() should not rely on the DateFormatSymbols.getZoneStrings() implementation, as it violates the spec that reads "The localized time zone names available from the implementations of this class are also the source for the DateFormatSymbols.getZoneStrings() method." So, I use this bug id for TimeZone.getDisplayName() to not to rely on DateFormatSymbols.getZoneStrings() method. ###@###.### 2005-05-24 19:47:12 GMT The quoted part did not explain the problem that I wanted to point out. The problem here is that TimeZone.getDisplayName() is affected by the DateFormatSymbolsProvider implementations and all the TimeZoneNameProvider implementations are currently ignored, which should not be. ###@###.### 2005-05-26 00:37:53 GMT
24-05-2005