If you ever write some HTTP endpoint where tabulated data is returned, you could quite reasonably return RFC 4180 style CSV.

However, if your API ever interfaces with users in a corporate environment, parsing simple comma-separated UTF-8 CSV is suddenly quite beyond the reach of however is nibbling at your endpoint, so why not code up a simple little reusable bit of code where you can write any simple tabular data (string, numbers, and dates, in one or more sheets of data made up of rows and columns) that lets you choose the output format? A zip-archive of CSV-files (one per sheet), JSON, ODS, or XLSX; pick your poison.

I did just that, and while it is perfectly doable, any low-level, low-resources, low-dependency approach will mean actually touching the XML in LibreOffice's ODS (fine), and Microsoft's OOXML (…).

This is how you write a date in a cell in both.

ODS:

            <table:table-row table:style-name="ro1">
                <table:table-cell office:value-type="date" office:date-value="2021-04-10T12:34:56" calcext:value-type="date">
                    <text:p>10/4/2021, 12:34</text:p>
                </table:table-cell>
            </table:table-row>
            

XLSX (OOXML):

            <row r="1" ht="12.8">
                <c r="A1" s="1" t="n">
                    <v>39448.5</v>
                </c>
            </row>

And of course it makes perfect sense to hardcode the cell coordinate there. It's not like you would dynamically generate a bunch of cells (…).

> However, if your API ever interfaces with users in a corporate environment, parsing simple comma-separated UTF-8 CSV is suddenly quite beyond the reach of however is nibbling at your endpoint

Excel can directly ingest a CSV file served over an URL as data source, with the Accept header manually set to text/csv.

I wrote a backend once that supported this feature so that management could pull whatever data they wanted off an internal application without pestering me. They could literally take the URL of a page and pull it as a CSV file as-is.

Anybody who knows a bit of Excel can pull that data themselves by following a set of simple instructions.

I was not aware there was an RFC for CSV, but the concept of "simple comma-separated UTF-8 CSV" is, in my experience, not something that exists. In a previous job, a chunk of my work was taking CSV files that were given to us and writing tooling to process them into a structured form for import elsewhere (typically we'd do a few test runs, and finally do a cut-over with final data, so it had to be scripted.)

During this I saw just about every variant of CSV and character encoding known to man, often inside the same file. Once I had a file that had UTF-8, MARC-8, Latin1, and (yes really) VT100 control codes. All in one file.

All in all, I'd prefer something that actually could be validated for some sort of correctness (this said, another time I got an XML export from some software that was invalid XML, so...)

Storing dates as numbers in a spreadsheet has been a thing since the first spreadsheet program I know of. Microsoft picked "days since 1900". If you're on UNIX, you may prefer using "1199188800" instead.

Other than that, the difference is pretty minor. ODS is very verbose and stores the content of the cell twice for some reason, but the XML trees are essentially the same.

The best way for corporate interaction is to export to whatever the hell Microsoft Excel accepts as an external data source, because .xslx files can natively import remote data that way. Hope your customers' computers are all configured for en_US mode, though, because CSVs aren't as universal as people pretend they are.