3 ms·

I agree and as a result I have completely abandoned CSV. I use the industry standard that everyone understands: ECMA-376, ISO/IEC 29500 aka .xlsx. Nobody has

I agree and as a result I have completely abandoned CSV. I use the industry standard that everyone understands: ECMA-376, ISO/IEC 29500 aka .xlsx. Nobody has any problems producing or ingesting .xlsx files. The only real problem is the confusion between numbers and numeric text that happens when people use excel manually. For machine to machine communication .xlsx has never failed me.

Hackbraten 2y ago
Off the top of my head: https://learn.microsoft.com/en-us/office/troubleshoot/excel/1900-and-1904-date-system https://learn.microsoft.com/en-us/office/troubleshoot/excel/... Now you might argue that ECMA-376 accounts for this, because it has a `date1904` flag, which has to be 0 for 1900-based dates and 1 for 1904-based dates. But what does that really accomplish if you can’t be sure that vendors understand subtleties like that if they produce or consume it? Last time I checked (maybe 8 years ago), spreadsheets created on Windows and opened on Mac still shifted dates by four years, and the bug was already over twenty years old at that time. And the year-1904 issue is just the one example that I happen to know. I have absolutely zero confidence in anything that has touched, or might have touched, MS Excel with anything short of a ten-foot pole.
Gormo 2y ago
Parsing Excel files in simple data interchange use cases that don't involve anyone manually using spreadsheets is an instance of unnecessary complexity. There are plenty of alternatives to CSV that remain plaintext, have much broader support, and are more rigorous than Excel in ensuring data consistency. You can use JSON, XML, ProtoBuf, among many other options.
- eternauta3k 2y ago
  But everyone already has a GUI installed for editing xlsx files...
  - Gormo 2y ago
    Which introduces even more problems when manually editing files is out of scope.

Hackbraten 2y ago

Off the top of my head: https://learn.microsoft.com/en-us/office/troubleshoot/excel/1900-and-1904-date-system https://learn.microsoft.com/en-us/office/troubleshoot/excel/... Now you might argue that ECMA-376 accounts for this, because it has a `date1904` flag, which has to be 0 for 1900-based dates and 1 for 1904-based dates. But what does that really accomplish if you can’t be sure that vendors understand subtleties like that if they produce or consume it? Last time I checked (maybe 8 years ago), spreadsheets created on Windows and opened on Mac still shifted dates by four years, and the bug was already over twenty years old at that time. And the year-1904 issue is just the one example that I happen to know. I have absolutely zero confidence in anything that has touched, or might have touched, MS Excel with anything short of a ten-foot pole.

Gormo 2y ago

Parsing Excel files in simple data interchange use cases that don't involve anyone manually using spreadsheets is an instance of unnecessary complexity. There are plenty of alternatives to CSV that remain plaintext, have much broader support, and are more rigorous than Excel in ensuring data consistency. You can use JSON, XML, ProtoBuf, among many other options.

eternauta3k 2y ago
But everyone already has a GUI installed for editing xlsx files...
- Gormo 2y ago
  Which introduces even more problems when manually editing files is out of scope.