I've done some testing, and some reading in the docs. Now I'll post my speculation.

Date::Manip's DateParse() function, in scalar context, returns a string that looks like yyyymmddhh:mm:ss.

Reading in the docs for MySQL here: http://dev.mysql.com/doc/mysql/en/DATETIME.html... I don't see where the format returned by Date::Manip's DateParse() function is a format recognized by MySQL. You probably need to at least massage the format by removing the colons from the string. At that point MySQL's date field should recognize the format and act appropriately.

Reading further in the documentation for Date::Manip I found this nugget of information:

INTERNAL

When a date is parsed using ParseDate, that date is stored in an internal format which is understood by the Date::Manip routines UnixDate and DateCalc. Originally, the format used to store the date internally was:

   YYYYMMDDHH:MN:SS
[download]

It has been suggested that I remove the colons (:) to shorten this to:

   YYYYMMDDHHMNSS
[download]

The main advantage of this is that some databases are colon delimited which makes storing a date from Date::Manip tedious.

In order to maintain backwards compatibility, the Internal variable was introduced. Set it to 0 (to use the old format) or 1 (to use the new format).

You can set the internal representation of Date::Manip's date string by using the Date_Init() function. Setting Date_Init('INTERNAL=1'); before you call DateParse() will force the return value of DateParse() to look like, "YYYYMMDDHHMMSS" (note, no colons).

That's just one possibility. Not sure if I'm on target, because I haven't tested the theory, but give it a try and see if it solves your problem.