Many a time, we've seen a program reach out into the database for date times. It's annoying to see, but not entirely stupid- if you can't rely on your web servers having synchronized clocks, the centralized database may very well be the only place you can get a reliable date/time value from. This ends up meaning you get a lot of date formatting happening in the database, but again- if it's the only reliable clock, you can't do better.
Unless you aren't even looking at a clock. Mendel sends us this C#:
string edi_error_transmit_date_s = "to_date(substr('" + datetime.InnerText + "',1,19),'yyyy-mm-dd\"T\"hh24:mi:ss')";
string comment_txt_s = "'Failure : time out = '||to_char(" + edi_error_transmit_date_s + ",'dd-mon-yyyy hh24:mi:ss')'";
datetime.InnerText
is a user input field- a user entered this date. The rest of the expression is an Oracle SQL expression, and as you can see, we're slowly building up a query through string concatenation of user provided inputs. Say hello to SQL injection, but obviously it'd make much more sense to use the build-in C# functions than do this.
Based on personal experience, I wonder if this person ends up in a similar position I was, once upon a time. Many years ago, I worked at a place that had pretty strict deployment processes for getting code promoted to even test application servers, but no one had any rules about how code got promoted to database environments. In fact, I could log into the production database and make changes to my heart's content (yes, terrifying, I know). But the result is that our web code was a thin wrapper around database code, because the more work I did in the database, the more I could iterate and deliver new features without having to go through any bureaucratic checkpoints.
The result was code that was a lot of "just call into the database to do real work", though I mostly did this through stored procedures, and definitely didn't munge together strings for SQL injection attacks.