Not something new...

But something I see people learning over and over and over again.

I was reminded of a recently asked asktom question - regarding an "intermittent" 'Oracle' bug in a java application ('Oracle' used for sarcasm on my part).

I was reading the current Steven Feuerstein's Blog entry (read that link before going on). It was exactly the same problem found by the java developers on asktom - which they were certain would be an 'Oracle bug' (hint: it wasn't, it was clearly and demonstrably in their code).

Funny, I see the pattern so often that I saw the bug in both bits of code almost immediately. It jumped out and hit my in the face.

SPOILER ALERT: don't read past here if you want to test your ability to find the bug, read Steven's article first.

Maybe I'll put in a request for the to_date function to be overloaded to accept a date as input and just return that date as output.

edit: added after *thinking* about what I just said...

That of course would never work. People are expecting the date format to be applied to the string, so just returning the date could of course NOT be the right thing to do. I guess the overload would have to turn:

to_date( DATE, 'fmt' )

into

to_date( to_char(date,'fmt'), 'fmt' )

instead of

to_date( to_char(date, IMPLICIT_FORMAT ), 'fmt' )

as it does now, but it would be a HUGE change to existing code that 'relies' the way it currently works...

The to_date function takes a string as input and since the date can be converted to a string - it is. I've seen MANY people use:

to_date( date )

to "truncate" a date (horrible idea - not only slow, but RISKY) - it would break their code (not that it isn't already broken) so it would probably be questionable...

Important enough to point out to a wide audience though - beware implicit conversions and watch out for to_date( of a date )!