Why not return dates as a string from the database?

Dates, DateTimes and really any other typed object, should generally be left in their properly typed format until the moment you need them to be made into some other type - especially when that type is a human readable form, and especially when it's a lossy/one-way sort of conversion.

Why? Because it is assumed that the type provides you with lots of handy built in functionality, like proper equality testing, comparison (greater than, less than), time zone and locale functionality (especially important for anything time-related), etc. If you decide you want to support Americans and the "Month Day[th], Year" format as well as the common British style of "Day Month Year", or the ISO standard of "Year-Month-Day"? What would you do if it was a string and you needed to make that change, parse it back into a Date? Ugh, no thanks - there are many evils and dastardly bugs that way, which are best avoided entirely.

More specifically, you mentioned tiered architecture, which has the presentation layer separate from the data later. This is actually the other big reason to pass a Date as a Date and not a string - because what type of string formatting should the date be put into? English, Chinese, with or without seconds/milliseconds, full month name or digits, will you want to sort on the date field later (sorting on a string demands a certain string format if you want it to work right), etc? This is all a question of presentation - how the user should view the data - and putting that logic anywhere else would limit the advantage of having tiered architecture in the first place. The database should not need to know or care how you'll want to view date in the future.

Finally, nearly all complex applications (which is what tiered architectures are for) that care about time will inevitably use times/dates in many, many different ways, and often at all different levels of the architecture. The typed objects related to times and dates exist for a really good reason: time itself, and especially human calendar systems, are weird and hard. Ultimately times and dates are not strings for the same reason that integers and floating points aren't strings, and it will only make your life harder if you try to pretend they are really just arrays of characters, because they just aren't.

He is saying to use the web server to convert the data time to a string. I am saying do it on the database server and not the web server. Why do you think that is better? - M T Head

I want to know the type.

I really don't care if your database stores information in a string, some ints, or bytes, because, well in the end it's always bytes anyway. That string taking up more space than is needed in your database doesn't bother me. What bothers me is running into dates like this:

11/10/2016

And not knowing if that's the eleventh month or the tenth month.

But it's validated you say. Sure you put it through a validation processes. The date is perfectly correct. But here I am maintaining this thing and all I know is the date is a string. I can't even tell you what date this is.

"Tenth day of November in the two thousand and sixteenth year of our lord."

That's a string. One of our presentations needs it in that format. You said the database converts all dates to strings right? Have fun with that.

The database's job is to store data not present data. Sure, you could do that in strings but then you have to parse it out to make it useful to present for other formats. Storing it in a standard parsed form for whatever type the DB offers gets us as close to ready to present as we can be without having made a presentation decision. It really doesn't matter to me if the DB backs that type with a string or ints or bytes. So long as it knows what it's doing.

But when you don't let the DB know we're dealing with a date and store a date as a string you are prematurely presenting and favoring one presentation over all others. This forces all other presenters to parse before converting. No, the database is not a part of the presentation layer. Don't ask it to be.

This is undesirable for the same reason you wouldn't just want to blindly convert any type to a string as soon as it hits the application tier. There is a high likelihood you're going to want to use that object in some manner before presenting it to the user (if you even do present it to the user). For this specific example, imagine you needed to do some date math on the object. There is no downside to just converting the object to a string precisely before you display it.