FAQ-0439 Localized date formatting doesn't seem to work on MARM


FAQ-0439 Localized date formatting doesn't seem to work on MARM

» Symbian OS » Developer Knowledgebase » FAQ-0439

Classification:	Java	Category:	java.util
Created:	11/25/99	Modified:	06/22/2001
Number:	FAQ-0439
Platform:	ER5

Question:
I'm trying to format dates in a certain locale, i.e. using the dd/mm/yy format, for which I'm using code such as:

Locale locale = Locale.FRANCE;
DateFormat df = DateFormat.getDateInstance(locale).
String localisedDate = df.format(new Date());

On the WINS emulator I get the correct date formatting: dd/mm/yy, but on MARM the date comes out US-style as mm/dd/yy.
Is this due to a defect in the EPOC Runtime for Java?

Answer:
The reason for this discrepancy is that the classes.zip file supplied with the WINS emulator has a wide selection of different language resource bundles (LocaleElements classes), including French, associated with the java.text.resources.* package. But the version of classes.zip shipping with the English Series 5mx, for example, has only English resources. When getDateInstance() looks for the French resource file and fails to find it, a MissingResourceException is thrown in system code. However, the JDK 1.1.4 system classes catch this exception and handle it by returning a default US-style date display format of SimpleDateFormat("M/d/yy h:mm a").

A simple work around would be to put the French resources from classes.zip from the emulator into \system\java\classes on the 5mx and have the sis file for your app install the same on the target. This of course assumes that French resources are not already present. Checking whether this is true or not during installation via a sis file is not currently possible.

Further problems confront you if you seek to ascertain at run time whether the required locale resources are available, because the JDK 1.1.4 implementation of the DateFormat.getAvailableLocales() method reports the availability of all locales whether or not the associated resources are present on an EPOC device. Further, the getDisplayCountry() and getDisplayLanguage() methods of the Locale class do not follow documented behaviour, even when called on available locales, so cannot be relied on to check whether the non-existent resources reported by DateFormat.getAvailableLocales() are actually there or not.

Two alternative strategies you could however use are as follows:

1. Check whether an (unwanted) US-style default date format has been returned and use your preferred default instead.

2. Check explicitly whether the LocaleElements class you want to use is present and, if not, use your preferred default locale, e.g.

Locale locale; try{ Class t = Class.forName("java.text.resources.LocaleElements_fr");
locale = Locale.FRANCE
}
catch (ClassNotFoundException e) {
locale=Locale.getDefault();
}