You have to do this with Excel as well to avoid your data automagically being formatted and/or truncated.

So true... opening a CSV in Excel is like playing the lottery. Sometimes it opens fine, sometimes not, it even depends on the character encoding of the CSV and whether you double-click the file, open it or drag it inside Excel. Sometimes you get the "import text file" window where you have to choose the delimiter, sometimes everything gets in a single column, and sometimes you get what you want.

CSV is not a standard (rfc4180 exists but only very few things actually pay attention to it) so no behavior is a sane behavior when trying to import it.

You sound like a C compiler. "This is technically undefined behavior so whatever" is not a useful guiding principle for user interfaces.

A normal user interface would guide you away from using CSV in the first place.

In almost all situations where one could use CSV, a better, more structured, more standards-compliant, more optimized file format (like a SQLite database) would be a better choice.

In situations where people are opening a CSV file in an office-suite spreadsheet app, they probably didn't generate the data themselves. Lecturing them about how their spreadsheet should have been a database isn't likely to help, and describing SQLite's file format, which is well-documented but not a standard, as "more standards-compliant" than a file format with an actual RFC is bordering on ridiculous.

The Library of Congress, an agency of the legislative branch of the U.S. government thinks that SQLite3 [1] is a acceptable database format.

The Library of Congress has a small amount of SQLite files in its collections.

The Library of Congress also cites CSV [2], Comma Separated Values, as strictly specified in RFC 4180 as a acceptable dataset format. No other types of free-form CSV that aren't variants compliant with 4180 are accepted, and it also says that documentation and metadata needs to be supplied with additional separated archives in supported data formats.

The Library of Congress has 0 CSVs in its collections, and as a result no experience actually handling it.

I believe that if a widespread format such as CSVs have 0 files added to a reasonably well known and encompassing collection of human artifacts related to culture even with its ubiquity, it's a telltale sign that it isn't a standard at all.

[1] https://www.loc.gov/preservation/digital/formats/fdd/fdd0004...

[2] https://www.loc.gov/preservation/digital/formats/fdd/fdd0003...

This is all completely irrelevant. No office suite user gives a shit what the Library of Congress thinks about database formats, because spreadsheets are not databases, no matter how often you personally conflate the two.

Furthermore, the LoC's job is archiving. Your links have "preservation" in the url for a reason, and "preservation" is not what people do with spreadsheets. To strive for relevance, explore https://data.gov, where CSV is abundant, because it's in use by literally hundreds of state and federal agencies, often by people using spreadsheet software, and will continue to be so for years or decades to come, whether you understand why or not.

edit: Your assertions are wrong anyway, as the LoC does indeed have CSV artifacts in its collection. It is most often in a Zip file and catalogued as "compressed data," which is probably why your perfunctory search did not unearth it. Some random counterexamples to your claim:

https://www.loc.gov/item/2022482299/

https://www.loc.gov/item/2020446966/

https://www.loc.gov/item/2023590205/

https://www.loc.gov/item/2018655320/

> This is all completely irrelevant. No office suite user gives a shit what the Library of Congress thinks about database formats, because spreadsheets are not databases, no matter how often you personally conflate the two.

I did not conflate database and dataset. I specifically described the two types. The Library of Congress specifically describes the two types.

You decided that "others" think that database and dataset are conflated, and that they are wrong.

> edit: Your assertions are wrong anyway (...) Some random counterexamples to your claim:

It's not my assertion, it's a assertion by the Library of Congress itself. The Library declares that it has no experience directly handling CSV.

> "LC experience or existing holdings": None in relation to collection holdings [1]

> "LC experience or existing holdings": "Report of actual practice at the Library of Congress." [2]

[1] CSV, Comma Separated Values (RFC 4180) - https://www.loc.gov/preservation/digital/formats/fdd/fdd0003...

[2] Format Descriptions: Explanation of Terms, Local Use - https://www.loc.gov/preservation/digital/formats/fdd/fdd_exp...

This will be my last response to you, since you seem to be ignoring actual points and veering into irrelevant pedantry, which is not particularly helpful to anyone. But because you keep structuring your posts with links in pursuit of a veneer of credibility, like some kind of reverse-Batesian mimicry, wherein something toxic might mimic something palatable in order to lure unsuspecting consumers, I will summarize for the benefit of our readers.

You asserted that "In almost all situations where one could use CSV" there would be a better choice, and suggested a database format. Aside from weasel words like "almost" making the statement inapplicable, the assertion itself is impracticable, for the reason I discussed, viz. in most situations where one is using CSV, one did not choose the format. Nothing you have said (or, I speculate, can say) contradicts this central point.

Your blathering about the Library of Congress is completely useless, since you appear to extract from a specific datum (the Library of Congress preservationists reporting no preferential experience with the format in relation to their collection) the irrelevant misinformation "The Library of Congress has 0 CSVs in its collections," which has a remarkable combination of qualities, i.e. not only does it have no bearing on the topic of this thread, it is also a lie, or at the very least a mistake borne of an inability or unwillingness to read the text you keep linking.

So in conclusion, nothing you have contributed to this discussion is of use to any office suite user while considering the ease of opening CSV files, and even if the information you have provided were of any utility value, it's not reliable. Congratulations on a perfect record, then, of not helping. I hope for the sake of those around you that your skills at identifying relevance and pursuing accuracy increase markedly and quickly.

I've just tried opening csv in LibreOffice and it asked me for it too. However sane options were already selected so it was just one additional click.