Ticket #5683 (closed defect: fixed)

Bug contains 2 commit(s) | SVN Diffs for #5683

 

Opened 3 years ago

Last modified 3 years ago

Incorrect Date format for the Chinese locale.

Reported by: paules@... Assigned to: yoshito
Priority: critical Milestone: UNSCH
Component: formatting Version: 3.6
Keywords: Cc: bjiang@us.ibm.com
Load: Xref: e181423
Java Version: Operating System:
Project (C/J): ICU4J Weeks:
Review: srl

Description

Incorrect Date format for the Chinese locale.

When formatting a date for the Chinese locale, the resulting formatted date string is not correct. In Chinese 2007/4/9 should localized as 2007 Year 4 Month 9 Day ("Year","Month" and "Day" are translated to Chinese).

Test Case:

See attached.

Notes:

1) This defect was found using ICU v3.6.0 as provided by Eclipse 3.3 M6 (com.ibm.icu_3.6.0.20061215.jar).

2) This defect is blocking the Eclipse TPTP defect https://bugs.eclipse.org/bugs/show_bug.cgi?id=181423.

3) This defect was found on Windows Vista.

Attachments

ChineseDateTest.java (0.7 kB) - added by paules@ca.ibm.com on 04/13/07 06:33:59.
Chinese Data Test.
test_results.JPG (27.1 kB) - added by paules@ca.ibm.com on 04/13/07 06:34:30.
Chinese Data Test Results.

Change History

04/13/07 06:33:59 changed by paules@...

  • attachment ChineseDateTest.java added.

Chinese Data Test.

04/13/07 06:34:30 changed by paules@...

  • attachment test_results.JPG added.

Chinese Data Test Results.

04/13/07 06:53:44 changed by yoshito

  • weeks changed.
  • xref changed.
  • revw changed.

The attached image indicate that ICU uses locale data for "zh" (a parent locale for both Simplified & Traditional Chinese). The locale data is from Common Locale Data Repository (CLDR - http://www.unicode.org/cldr/). At least, ICU works well as designed. In general, use of Java Locale "zh" is discouraged.

04/13/07 23:58:20 changed by grhoten

  • status changed from new to closed.
  • resolution set to wontfix.
  • os deleted.

The data comes from CLDR, and ICU can't change it. Please submit the change request through the CLDR survey tool. http://www.unicode.org/cldr/survey_tool.html

04/16/07 07:33:19 changed by yoshito

  • status changed from closed to reopened.
  • resolution deleted.

I'm pretty sure this is not an ICU4J problem and the root cause is that the date pattern for zh is picked on the environment for some reasons. Until the associated eclipse bug is resolved and identified, I would like to leave this bug open for now.

04/16/07 07:33:29 changed by yoshito

  • owner changed from somebody to yoshito.
  • status changed from reopened to new.

04/16/07 07:33:43 changed by yoshito

  • status changed from new to assigned.

04/16/07 09:34:24 changed by yoshito

  • priority changed from major to critical.

It was actually a data bug in ICU4J 3.6. ICU4C 3.6 is fine. When locale data for ICU4J was generated, date format pattern data in zh_Hant.res was broken (same patterns with root). It looks this is a bug in LDML2ICU tool introduced after ICU4C 3.6 release/before ICU4J 3.6 release. Locales impacted by this probem are all Traditional Chinese locales (zh_Hant, zh_Hant_TW, zh_Hant_HK, zh_Hant_MO and its aliases - zh_TW, zh_HK and zh_MO).

It looks the same issue is found in the trunk.

04/16/07 20:18:31 changed by yoshito

  • xref set to e181423.
  • revw set to srl.

The problem was caused by the LDML2ICU tool problem. Some Chinese alias bundles contained extra data other than %%ALIAS in 3.6. The problem can be resolved in two ways. The first solution is to remove the unnecessary data from these alias bundles. The second solution is to detect bundle as an alias even any keys other than %%ALIAS are included. Actually the tool bug was already fixed after 3.6 release. At this stage, we do not want to re-generate icu data for 3.6.1 release, because we need to spend time to validate the data generated by updated tool. So I decided to take the second solution for 3.6.1 release. The issue in trunk is slightly different. We decided to relocate some locale data to language only bundle and the incorrect date pattern for zh_Hant locale was introduced because of the transition is not yet completed. CLDR1.5 will include the data which is necessary for supporting zh_Hant locale properly. So the issue should be resolved in next data refresh.

Although the fix done in 3.6 stream does not make the current trunk issue resolved, the change makes the code more robust against malformed alias bundles. So I merged the code and its test code into the trunk as well.

08/17/07 17:52:04 changed by srl

  • status changed from assigned to closed.
  • resolution set to fixed.

Add/Change #5683 (Incorrect Date format for the Chinese locale.)




Anti spam check: