-
Bug
-
Resolution: Fixed
-
P3
-
11
-
master
-
Verified
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8207083 | 12 | Rachna Goel | P3 | Resolved | Fixed | b03 |
JDK-8207433 | 11.0.2 | Rachna Goel | P3 | Resolved | Fixed | b01 |
JDK-8207543 | 11.0.1 | Rachna Goel | P3 | Resolved | Fixed | b02 |
JDK-8207171 | 11 | Unassigned | P3 | Closed | Fixed | b22 |
jdk 11 build 12 failed
jdk 11 build 11 passed.
With default provider to run below test: "java Test2", Short week days, NaN value and timezone name are inconsistent between CLDR and Java in zh_CN, zh_TW locales.
For example, in CLDR, short week days in zh_CN is:<day type="sun">周日</day>, but Java output "星期日".
public class Test2 {
public static void main(String[] args) throws Exception {
DateFormatSymbols dfs;
DateFormat df;
DecimalFormat decimalf;
DecimalFormatSymbols decimalfs;
Locale zh_CN = Locale.forLanguageTag("zh-CN");
Locale zh_TW = Locale.forLanguageTag("zh-TW");
System.out.println("DateFormatSymbols.getShortWeekdays:");
dfs = DateFormatSymbols.getInstance(zh_CN);
String[] shortDays_zh_CN = dfs.getShortWeekdays();
System.out.println("locale:zh_CN:" + shortDays_zh_CN[Calendar.SUNDAY]);
dfs = DateFormatSymbols.getInstance(zh_TW);
String[] shortDays_zh_TW = dfs.getShortWeekdays();
System.out.println("locale:zh_TW:" + shortDays_zh_TW[Calendar.SUNDAY]);
System.out.println("DateFormat.getTimeInstance.format:");
TimeZone tz = TimeZone.getTimeZone("America/Los_Angeles");
long l = 882869989318L;
df = DateFormat.getTimeInstance(DateFormat.FULL, zh_CN);
df.setTimeZone(tz);
String fmt_zh_CN = df.format(new Date(l));
System.out.println("locale:zh_CN:" + fmt_zh_CN);
df = DateFormat.getTimeInstance(DateFormat.FULL, zh_TW);
df.setTimeZone(tz);
String fmt_zh_TW = df.format(new Date(l));
System.out.println("locale:zh_TW:" + fmt_zh_TW);
System.out.println("DecimalFormat.getNaN:");
decimalf = (DecimalFormat) NumberFormat.getInstance(zh_CN);
decimalfs = decimalf.getDecimalFormatSymbols();
String nan_zh_CN = decimalfs.getNaN();
System.out.println("locale:zh_CN:" + nan_zh_CN);
decimalf = (DecimalFormat) NumberFormat.getInstance(zh_TW);
decimalfs = decimalf.getDecimalFormatSymbols();
String nan_zh_TW = decimalfs.getNaN();
System.out.println("locale:zh_TW:" + nan_zh_TW);
}
}
Except output:
DateFormatSymbols.getShortWeekdays:
locale:zh_CN:周日
locale:zh_TW:週日
DateFormat.getTimeInstance.format:
locale:zh_CN:北美太平洋标准时间 上午1:39:49
locale:zh_TW:上午1:39:49 [太平洋標準時間]
DecimalFormat.getNaN:
locale:zh_CN:NaN
locale:zh_TW:非數值
Actual output:
DateFormatSymbols.getShortWeekdays:
locale:zh_CN:星期日
locale:zh_TW:星期日
DateFormat.getTimeInstance.format:
locale:zh_CN:上午01时39分49秒 PST
locale:zh_TW:上午01時39分49秒 PST
DecimalFormat.getNaN:
locale:zh_CN:?
locale:zh_TW:?
Setting CLDR provider explicitly to run above test, "java -Djava.locale.providers=CLDR Test2", it can get expected output.
- backported by
-
JDK-8207083 Short week days, NaN value and timezone name are inconsistent between CLDR and Java in zh_CN, zh_TW locales.
- Resolved
-
JDK-8207433 Short week days, NaN value and timezone name are inconsistent between CLDR and Java in zh_CN, zh_TW locales.
- Resolved
-
JDK-8207543 Short week days, NaN value and timezone name are inconsistent between CLDR and Java in zh_CN, zh_TW locales.
- Resolved
-
JDK-8207171 Short week days, NaN value and timezone name are inconsistent between CLDR and Java in zh_CN, zh_TW locales.
- Closed
- duplicates
-
JDK-8207033 ZonedDateTime could not parse timezone name with zh_CN locale correctly.
- Closed