Okay, let me suggest to you that it seems very likely to me that you have a red herring problem here, because it seems very, very unlikely to me that a change to the client of a client/server system would cause an SQL insert, on the server of course, to throw a data-conversion error.   Now, perhaps this change revealed the existence of a problem that has existed for a long time ... but I frankly doubt that, too.   What seems most likely to me right now is that there is a configurable setting on the client side upon which this program depends.   The dependency might not be documented in your company’s IT logs (if you keep them), and when/who made the setting probably isn’t recorded either, but it is something that is affecting date/time conversions.   It could be an Oracle setting or it could, perhaps more likely, be a setting related to ODBC.   It probably has been reset to some kind of default.   You should look in both places, because an Oracle-client upgrade would not necessarily be known to ODBC.

Now, none of us are (nor could we be) a “code-writing service” for you, such that you can expect to toss a snippet of code at us and say, “please fix this for me.”   (That sort of thing requires a Crystal Ball, and mine’s busted.)   We are here to help, but You are going to have to do some detective work here, with regards to this software that only you know best.   Start with wherever this data originates, and trace it forward step-by-step from there, no matter where it goes and whether or not it involves Perl.   (In this case it is quite probable that it does not.)   HTH.™