date_convert_from_custom() should fail more gracefully on letter/value count mismatch

I had a date field set to take date+time, but whenever the user manually entered a time, it reverted to 0:00 on save. I spent several hours debugging this today and found the cause, and I think this could be avoided with smarter validation.

Scenario:
Date field input format in the CCK field settings is F j, Y G:i T (e.g. March 17, 2011 17:37 EDT)
(The G there is hour in 24-hour format.)
On the node form, the 'time' part of the date field appears as a textarea in the format hh:mmaa (with am/pm). So the user enters "2:22am" for example.

When the form it saves, it goes through date_convert_from_custom(). Line 607 has logic with the comment: "if we did not find all the values for the patterns in the format, abort". In this case the number of "letters" don't match the number of "values", because the values have am/pm (a in date() code) but the letters don't. So it simply aborts. The time is then empty, so it gets returned as 0:00:00 (midnight).

The solution is to change the input format on the field settings to F j, Y - g:ia (e.g. March 17, 2011 - 5:40pm). Then it saves the field properly.

So the solution was very simple once I figured out what was going wrong, but someone without the time or wherewithal to debug this wouldn't be able to figure that out. I think this needs to be validated better: either date_convert_from_custom() needs to fail more gracefully, or check the pattern against the value more thoughtfully, or validation needs to happen on the field settings and/or node forms to prevent that kind of input format mismatch.

Any ideas for the best way to handle this for future non-dev users?
Thanks.