You're lucky. We always try to explain that CSV is a mostly-clean format while XLS and XLSX are a mess.
Yet, most of the time customers insist on XLS export, and we are happy if they at least acccept XLSX instead.
Yet, most of the time customers insist on XLS export, and we are happy if they at least acccept XLSX instead.
I suspect you're thinking of something like "CSV as outputted by Excel with the default settings", which may be clean and unambiguous, but is far from the only CSV in the world.
For that reason (and I'm just saying this generally, not targeted at the comment I'm replying to), always use the most mature CSV output library you can find for your stack. Never write your own CSV export code by bashing strings together unless you have no other choice because you're working in some stack that doesn't have or can't use existing CSV libraries.
(You can ignore the RFC for CSV too; it's not "wrong", it's just one particular flavor that was declared long after the horses had left the barn, learned to form a horse civilization, discovered the atom bomb and bombed themselves back to being plain horses again. It barely rises to the level of being "advisory" in practice.)
EDIT: I will add that EXPORTING to XLS/X is usually quite straightforward and makes users happier than getting a CSV often times. Until they start wanting to get crazy with template design and then you get into Excel styling application and you're back to hating it all over again.
http://www.aspose.com/products/cells
[NB I have no connection with Aspose, just been a happy customer for many years].
Excel encodes dates and times as floating point numbers. The date / time-ness of a cell is encoded in its format. Some of the formats are hard-coded, some float depending on locale, and some use explicit format-pictures embedded in the styles.
But of course there's no guarantee that the user has formatted a cell with a date as a date. Sometimes the user has pasted a US-format date into a copy of Excel running in a UK locale, so dates that fit have day and month swapped, while dates that don't fit show up as strings. This is non-trivial to handle in the general case. I've had to add customer-specific workarounds for this case in particular.
You'd think when Microsoft came up with their new shiny file formats they'd actually make them new and shiny and good.
But nope.
The worst thing Microsoft ever did to Excel was even translating the formula functions in different languages. So SUM() isn't actually called SUM() in half of Europe...