-
Bug
-
Resolution: Won't Fix
-
P3
-
7
-
generic
-
generic
Java: 5, 6, 7 all have this problem. It's not a regression.
In S. Chinese(zh_CN), When the time of the date is at 0:00, the midnight of a day, and using DateFormat to format the date object, the output woulde be
ShangWu 12:00, rather than 00:00. This is very misleading in Chinese, because in China, there is no covention that localized 12:00 am means 0:00 at midnight.
In FormatData_zh_CN.java, ah is used in DateTimePattern. This follows the standard time pattern in CLDR. I check the national standard for date and time in China, GB/T 7408-2005. There is no hour based on 1 to 12. hh means 00 to 24, not 1 to 12 or 0 to 11. So, in zh_CN, HH should be used to replace ah in standard time pattern. This change also fits the national standard.
I also reported the defect to unicode.org via http://www.unicode.org/reporting.html.
Attached is the source code of the program that can reproduce the problem in zh_CN, zh_TW, and ko. I am sure that it's a defect in zh_CN because I am the native speaker and check the national standard published by the government, but for zh_TW and ko, I am not sure.
The bug report I submitted to unicode is also attached.
Confirmed with language specialists that this problem is zh_CN only. Current time format is OK in zh_TW and ko.
In S. Chinese(zh_CN), When the time of the date is at 0:00, the midnight of a day, and using DateFormat to format the date object, the output woulde be
ShangWu 12:00, rather than 00:00. This is very misleading in Chinese, because in China, there is no covention that localized 12:00 am means 0:00 at midnight.
In FormatData_zh_CN.java, ah is used in DateTimePattern. This follows the standard time pattern in CLDR. I check the national standard for date and time in China, GB/T 7408-2005. There is no hour based on 1 to 12. hh means 00 to 24, not 1 to 12 or 0 to 11. So, in zh_CN, HH should be used to replace ah in standard time pattern. This change also fits the national standard.
I also reported the defect to unicode.org via http://www.unicode.org/reporting.html.
Attached is the source code of the program that can reproduce the problem in zh_CN, zh_TW, and ko. I am sure that it's a defect in zh_CN because I am the native speaker and check the national standard published by the government, but for zh_TW and ko, I am not sure.
The bug report I submitted to unicode is also attached.
Confirmed with language specialists that this problem is zh_CN only. Current time format is OK in zh_TW and ko.