We all know that you never trust any data entered by the user. You have to parse it, and wrap it so you don't have the "little Bobby DropTables" problem.
Granted, I don't think the answer is critical for either performance or usability, but this question has popped into my brain.
Suppose the user is entering a date. The program doesn't know ahead of time what format it will be in, its up to the user.
2011-11-30 would be a nice format, but they are likely to entry Nov 30, 2011 or 11/30/2011 or durn near anything else.
I see two basic approaches. I'm wondering which is better, in the sense of style, good code, ease of understanding, or gross performance.
1) use a series of regex to identify which format its in, and then use that format in a SimpleDateFormat to pull out the values.
2) have a list of possible formats, and try them, in order, until you get a good value.
I agree with Bear regarding using a Date picker, I think giving the user concrete choices or options and also make it easier to use and less confusing for the end user. That way we might be able to get correct inputs from the user.
HTML5 has a datetime form input type. Google Chrome has some support for it, Opera has excellent support for it (showing complete pickers for days, weeks and months). Unfortunately, that's as far as you'll get; Firefox still doesn't support it. I'd go with the jQuery picker as well. You still need to validate on the server, but at least you'll have one format to check.
Using multiple DateFormats works (using the parse method that takes a ParsePositoon, to prevent all the ParseExceptions), but you can't recognize all formats. Even worse would be language specific input; an English user could type "Nov 30 2011" or "Nov 30, 2011", but a Dutch user would use "30 nov 2011".
Basically the problem with guessing the user's date format -- which is what you're discussing -- is that you might guess wrong. So, let's do the risk analysis. What bad things could happen if you interpret a date as 2012 June 3 instead of 2012 March 6?