When our dateTimeEntry component was YUI based and more rendered from the server, we had the ability to support any localisation that Java supports, automatically, as of ICE-6081. Since transitioning to basing dateTimeEntry off of jQuery, with it's rendering being done client side in javascript, we've used a model where the localisation is up to the application, as demonstrated in dateTimeEntry-locale-tutorial.

It would be good to provide a means to hook into the faces-config.xml supported-locale and default-locale entries, and provide a means of populating the javascript locale structures based off of the Java server DateFormatSymbols.

One necessity is that f:convertDateTime will take the client provided date string and pass it to a DateTimeConverter, which will use all of the Java in-built localisation strings, and cause conversion errors if the given string doesn't match the in-built strings. So it makes sense to make it use what it expects, and not encourage arbitrary strings from applications.