Taking a quick look through the controllers in the OpenMRS, in most places a CustomDateEditor for date binding is created like this:
binder.registerCustomEditor(java.util.Date.class, new CustomDateEditor(Context.getDateFormat, true))
IMO, this should be modified in all cases to:
SimpleDateFormat dateFormat = Context.getDateFormat();
binder.registerCustomEditor(Date.class, new CustomDateEditor(dateFormat,true, 10));
"setLenient(false)" prevents against entering bad dates by switching the day and month fields. For instance, right now if I enter a date by hand "2/23/2010" when the format is supposed to be "dd/mm/yyyy", OpenMRS does not complain, but saves the date as the utterly wrong "2/11/2011".
Adding the third parameter, "10" to the CustomDateEditor initialization enforces that only 10-digit dates are accepted (2 digit date, 2 digit month, 4 digit year, plus 2 separators). Without this, the system interprets 1/1/09 as 1/1/0009, which is also utterly wrong.
These problems seem fairly serious to me... I had to go through and correct 300+ bogus dates in the Haiti system.
Of course, this problem doesn't occur if data entry is done via the datepicker, but for trained data entry clerks with good typing skills, I think entered by hand would be the preferred method.