ChineseDateFormat : toLocalizedPattern() throws java.lang.IllegalArgumentException: Illegal pattern character 'l'
Description
The following code throws an IllegalArgumentException:
com.ibm.icu.util.ChineseCalendar chineseCalendar = new
com.ibm.icu.util.ChineseCalendar(
com.ibm.icu.util.TimeZone.getTimeZone("GMT+8:00"), Locale.CHINA );
chineseCalendar.setTimeInMillis((new Date()).getTime());
com.ibm.icu.text.SimpleDateFormat longChineseDateFormat =
(com.ibm.icu.text.SimpleDateFormat)chineseCalendar.getDateTimeFormat(
DateFormat.LONG, DateFormat.LONG, Locale.CHINA );
longChineseDateFormat.setDateFormatSymbols( new
com.ibm.icu.text.ChineseDateFormatSymbols( chineseCalendar, Locale.CHINA ) );
// The following line throws an IllegalArgumentException
String longFormatPattern = longChineseDateFormat.toLocalizedPattern();
The exception is:
java.lang.IllegalArgumentException: Illegal pattern character 'l'
at com.ibm.icu.text.SimpleDateFormat.translatePattern(SimpleDateFormat.java:1611)
at com.ibm.icu.text.SimpleDateFormat.toLocalizedPattern(SimpleDateFormat.java:1637)
at com.alphablox.blox.uimodel.core.DateFormatAdapterTest._testChineseFormatSymbols(DateFormatAdapterTest.java:138)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
Activity
Trac Comment by notes2—1970-01-01T01:23:03.000Z
Authorized persons, see private comment at:
http://bugs.icu-project.org/cgi-bin/private/icu-bugs-private?findid=4904
Trac Comment by auditor—1970-01-01T01:23:04.000Z
details:
Trying to get the localPatternChars for a ChineseDateFormat fails, because the default patterns include 'l' for the ChineseLeapYear, but this letter does not appear in the static DateFormatSymbols.patternChars. Each Calendar class provides a static localPatternChars that mirrors the list found in DateFormatSymbols, but provides localized characters. The translation pass simply takes each alphabetic character in the pattern, looks it up in patternChars, and then maps it to the corresponding character in localPatternChars. Since the 'l' does not appear, the lookup fails, and the code throws an exception "illegal pattern character".
Of course, the pattern character is entirely legal, it's the translation process that's broken. The localPatternChars is resource data that's independent of the calendar type and must match the hard-coded 'universal' patternChars string.
There are two general ways to deal with this problem, 1) fix it, and 2) patch it.
And fixing has two possible approaches, 1a) make it support arbitrary new calendars, and 1b) support just what we have.
Option 2, patching, is easiest. We just don't throw an exception, and leave the characters that don't have a translation untranslated.
Option 1a, fix just to support what we have, is next easiest. Look at the pattern characters for all the calendars we have, and make sure they are in the patternChars string, and make sure that all our localized pattern strings have the same number of characters. This does, however, require tweaking lots of data, some of which is in CLDR I expect.
Option 1b, fix for real, is the most work
Mon Oct 31 15:59:50 2005 dougfelt moved from incoming to formatting
Mon Nov 7 13:28:04 2005 dougfelt changed notes2: review: "" to "srl",
Fri Dec 16 11:18:07 2005 srl moved from formatting to fixed
Fri Dec 16 11:20:28 2005 srl changed notes2: xref: "" to "4978",
Sun Oct 22 07:33:45 2006 grhoten moved from fixed to closed
Trac Comment 3 by anonymous—2009-10-12T11:33:43.000Z
[mp3 песни скачать бесплатно|http://rapidshare.in.ua/]
