How to extract the date fields for locale-specific formatting in Java?

Question

I need to extract only the month and year information from a Java Date to display in a GUI. This date must be translated using the user locale. I know 2 ways for formatting localized dates:

1. Using DateFormat.getInstance(DateFormat.LONG, locale).format(date)
2. Using new SimpleDateFormat("yyyy M", locale).format(date)

For locale SIMPLIFIED_CHINESE and date 2013-02-18, this gives:

1. 2013年2月18日
2. 2013 2

We need to use the LONG format without day (2013年2月). [The variant 2 is clearly not acceptable since the ordering of year-month is not affected by the locale]. The problem could be: how to remove the day part (18日) from the long format ? I tried using the method format(Date date, StringBuffer toAppendTo, FieldPosition pos), but this allows only extracting the number part, not the extra character.

The pattern of the DateFormat.getInstance(DateFormat.LONG, Locale.SIMPLIFIED_CHINESE) is yyyy'年'M'月'd'日'. Extracting the day part would yield yyyy'年'M'月'. It seems to me that it's not possible to use Java's DateFormat standard to achieve this since the extra characters (年, 月 and 日) do not seem mapped to the corresponding field, but are simply characters without other semantic for the formatter.

I had a look to DateFormatSymbols and LocaleServiceProvider, but think it doesn't help. To me, the point of extension would be adding another date style to the getInstance(int style) method. But it doesn't seem possible without implementing it for all the Locale...

Is this analysis correct ? How to achieve this formatting in a clean way ?

Turntable

+1 : I can't see a way of doing this either. Maybe try JodaTime library instead. – Kumamoto

I tried the following without success: YearMonth.fromCalendarFields(cal).toString(DateTimeFormat.longDate().withLocale(locale)). – Turntable

Answer 1

I don't think that any pre-defined constants would exist for year-and-month formatting in zh-CN locale, so you have to format it.

  new SimpleDateFormat("yyyy年M月").format(date)

As SimpleDateFormat says (highlighted by me):

Date and time formats are specified by date and time pattern strings. Within date and time pattern strings, unquoted letters from 'A' to 'Z' and from 'a' to 'z' are interpreted as pattern letters representing the components of a date or time string. Text can be quoted using single quotes (') to avoid interpretation. "''" represents a single quote. All other characters are not interpreted; they're simply copied into the output string during formatting or matched against the input string during parsing.

So, it is safe to put chinese characters into the format string this way.

Since Java is Unicode, you can inline the characters in your source as long as you compile with unicode source character set. Otherwise you should read this String externally, e.g. from some Unicode property file or database.

Grandiloquent

Thus in short, Java doesn't provide a way to internationalize such formats. It must be implemented manually. – Turntable

Yes, that's a special date format. If there were a DateTime-like datatype which would represent month and year only, then we would have had bigger chance to have a built-in support for it. It is not so common, so you have to use this. IMHO DateTime-like datatypes are so complex topic anyway, that it is not worth to make it more complicated. – Grandiloquent

Another way to avoid encoding problems is to retrieve the translated value for style LONG and hardcode which part of the date pattern to keep pattern (in our case, discard the 4 last chars of the pattern). That gives: > final String patternFull =((SimpleDateFormat) DateFormat.getDateInstance(DateFormat.LONG, Locale.SIMPLIFIED_CHINESE)).toPattern();final String patternYearMonth = patternFull.substring(0, patternFull.length() - 4); – Turntable

Yes, that was my first idea (String manupulations), but there are variable number of characters (think of 9th and 10th), so you would have to parse it first. If the month character varies for each month, that is the better option. But as of my Chinese knowledge, that is not the case. – Grandiloquent