JDK-6369299 : java.text.SimpleDateFormat: toLocalizedPattern() returns inappropriate string for many locales
  • Type: Bug
  • Component: globalization
  • Sub-Component: locale-data
  • Affected Version: 5.0,7
  • Priority: P3
  • Status: Closed
  • Resolution: Won't Fix
  • OS: generic
  • CPU: generic
  • Submitted: 2006-01-05
  • Updated: 2013-05-29
  • Resolved: 2013-05-29
Related Reports
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Description
I'm working on a web UI component that accepts calendar data. The
component consists of (among other things) a textfield below which is
supposed to be a localized hint representing the expected format of
the date input, e.g. dd/mm/yyyy.

The component uses a java.text.SimpleDateFormat internally, and I
would like to use the toLocalizedPattern() method (and toLowerCase())
to produce a default hint. By default I do not set the pattern to use,
as SimpleDateFormat pattern will pick one that is appropriate for the
locale. 

However, when I use toLocalizedPattern() method, I only appear to get
a truly localized string for German (uuuu.MM.tt) . For other languages
I tried, including Swedish, French and Asian languages) I get the same
result as I would with toPattern(), that is, it is technically
appropriate for the locale, but the representation is made up by
strings that are only intelligible in English.

FWIW, I am Swedish and have also lived in France. In neither of those 
countries do I remember having filled in a form where the suggested 
date format was represented to me using English letters. Using Google 
to search on Swedish pages I get twice as many hits for ��������-mm-dd as for
yyyy-mm-dd (and if the first hits are representative, many of the
yyyy-mm-dd are used in JavaScript code). For French I get more than
four times as many hits for aaaa-mm-jj as for yyyy-mm-dd.

Comments
In latest CLDR, "Localized Pattern Characters" is deprecated. Changing current localized pattern characters in JRE will cause compatibility issue.
29-05-2013

EVALUATION The prerequisite to fix this CR is 6336885. 6336885 is targeted to 8-pool, so this CR is also targeted to 8-pool.
18-01-2011

EVALUATION To fix the CR, there needs to be some architectual change as prerequisite, to aviod compatibility issue. I have filed a CR 7012373. For this CR itself, it may need to be splieted into many sub CR, so that we can fix the incorrect localized dateformat pattern or pattern simbols.
14-01-2011

EVALUATION Transfer the CR to Masaki. I think fixing the CR in Java 7 is enough. thanks, Yong
23-02-2010

EVALUATION Although this is a localization issue, it would introduce a compatibility problem if we change the localized pattern characters, as shown with the bugs 4265184 and 4994312. One of possible solutions is to provide CLDR based locales through the locale sensitive services SPI.
09-01-2006