JDK-4261506 : DateFormatSymbols.getZoneStrings() does not contains default elements.
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.text
  • Affected Version: 1.2.1,1.2.2,1.3.0
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: generic,solaris_7,windows_nt
  • CPU: generic,x86,sparc
  • Submitted: 1999-08-10
  • Updated: 2001-11-06
  • Resolved: 1999-09-27
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.
Other Other Other
1.2.2_06 06Fixed 1.3.0Fixed 1.3.1Fixed
Related Reports
Duplicate :  
JDK-4267620 - wrong time offsets, and short time representation [Solaris's jdk1.2.1's TimeZone
Duplicate :  
JDK-4267616 - wrong time offsets, and short time representation [NT jdk1.2.1's TimeZone]
Relates :  
JDK-4112924 - RFE: Localized time zone display names
Relates :  
JDK-6373727 - CTE_REGTEST/Generic/4261506/Test.java failed on 142u11b2, 142u10b3 but passed on 142-fcs
Description
DateForamtSymbols.getZoneStrings() returns only current locale zone strings data. It does not contains default zone string names in DateFormatZoneData. For example, in ja (japanese) locale, DataFormatSymbols.getZoneStrings() returns only zone name for "Asia/Tokyo". Though other zone name (like, PST, EST) are defined in default DataFormatZoneData.java. This is very inconvinent for locale data localizer, since they cannot rely on default fallback mechanism.

The problem blocks the fix to #4112924.

koushi.takahashi@japan 1999-08-10

###@###.### 2001-11-06
This bug still occurs in Merlin build 84
Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: kestrel FIXED IN: kestrel INTEGRATED IN: 1.2.2_06 1.3.1 kestrel VERIFIED IN: 1.2.2_06 1.3 merlin-beta
14-06-2004
PUBLIC COMMENTS DateFormatSymbols "zoneStrings" that is used when SimpleDateFormat.format/parse() is called with "z" is now using ResourceBundle mechanism to get default (or root) resources. Thus, if L10N is not completed, some major timezone is not displayed as human readable form in most locale.
10-06-2004
SUGGESTED FIX Proposed backport of this fix to patch for JDK1.2.2 is in Attachments. A new New DateFormatZoneData has been created for locale en_US so that GMT+/-xxx will not be displayed for zones on the list from escalation customer. carolyn.lowenthal@Eng 2000-01-10
10-01-2000
EVALUATION Each time zone ID should/can be a key for localized strings. I18N will fix this lookup bug. Still L10N has to localize each DateFormatZoneData. masayoshi.okutsu@Eng 1999-09-01
01-09-1999