It's definitively a Dojo problem. If I go to http://dojocampus.org/explorer/#Dijit_Form%20Controls_Text%20Boxes_Date_Customized%201 with my locale set to dutch, It enters "2005 12 14" If I change it to english, it comes out as "14 December 2005". german comes out as "14. Dezember 2005". I'll see if I can file a problem report there.
Problems seem to appear only if you are generating the application with a different locale to the one used by your browser.
I'm certainly not changing locales between generating the application and viewing with my browser.
The reason I'm suggesting to change the default pattern to some numeric date representation, is that the current default just doesn't work out-of-the-box. It just works if your browser locale is English, German or French and other big language (Just trying some out. Polish Greek or Danish don't work either). Sure there is a work around for it, by specifying the format yourself, but you have to figure that out first. Any user with an "uncommon" locale, that will try out roo and sets up petclinic, won't be able to enter an Owner. Some people will loose interest, because it just doesn't work (although it's a fault in Dojo).
Furthermore, If YOU create a standard CRUD application using roo, you'll think it works great, until I try to access it, and won't be able to submit a form. It's really about giving people a false sense of flexibility. One my think "lets make the format "dd-MMMMM-yyyy", and you break your application. It's like promising the developer more than the framework of YOUR choice can offer.
I don't think that hard-coding a date format is sensible at this time as there were users that expressed the need for localized date formats in the past and I believe that the default settings work well.
I bet that ((SimpleDateFormat) DateFormat.getDateInstance(DateFormat.DEFAULT, Locale.getDefault())).toPattern(); always gives "d-MMM-yyyy" with any system default locale, as it's not the formatpattern, but the interpretation of it that's locale sensitive. So it's really hard coded atm as well. As I explained above, I don't think the default works well at all.
Another thing I noticed is that it's now possible to switch locale from the default interface. Shouldn't the localization be applied to this datepicker as well? I noticed there is localization support for the DateTextBox http://dojotoolkit.org/book/dojo-porting-guide-0-4-x-0-9/widgets/datepicker . That way, you can at least make sure your application behaves independent of the locale setting of you user.