Hacker News Reader

Comment by otikik | Hacker News Reader

In my country (Spain) we traditionally use commas as a decimal separator, but I think CSV should not support this.

The way I see it, CSV's purpose is information storage and transfer, not presentation.

Presentation is where you decide the font face, the font size, cell background color (if you are viewing the file through a spreadsheet editor) etc. Number formatting belongs here.

In information transfer and storage it's much more important that the parsing/generation functions are as simple as possible. So let's go with one numeric format only. I think we should use the dot as a decimal separator since it's the most common separator in all programming languages. Maybe extend it to include exponential notation as well, because that is what other languages like json support. But that's it.

I hold the same opinion about dates tbh.

(The same goes for dates, btw - yyyy-mm-dd or death)

View on HN

For time formats, use ISO 8601, and be sure to append a Z to the end to denote UTC (zulu time), and consider rejecting timestamps without it:

https://en.m.wikipedia.org/wiki/ISO_8601

The only real problem with that format is the distasteful "T" in the middle (but, hey, at least it is whitespace-free!)

The other distasteful thing is getting your hands on the actual ISO 8601 specs is pretty expensive, like 350 CHF, which is weird, because so many national standards bodies gave it official blessing, and so many things in the digital universe depend on it. Maybe that 'T' is optional after all!

There is RFC 3339, which is essentially “ISO 8601: The Good Parts” and, like all IETF RFCs, freely available: https://www.rfc-editor.org/rfc/rfc3339

What do you mean by csv shd not support this. Do you mean it was a historical mistake or new parsers shdnt be able to read it?

My opinion is that it was a historical mistake. I think if the format would have been clearly specified in Microsoft Excel humanity would have saved billions in parsing labour.

On the question wether new parsers shouldn't be able to read it... if I have to build them or maintain them, then *those* parsers shouldn't be able to read it. I don't want to have to deal with the whole messiness of the thing, and I know how to change Excel's locale to generate CSV in a reasonable format. If it's something that someone else maintains and I can mostly ignore the crazy number formatting as well as other quirks, I could live with it. But I would still prefer if they didn't implement any of it, because the extra code could make the parts that I need worse (for example, by provoking a segfault, or making a line ambiguous).

Even if it's parsers that other people use and I never use, I still would prefer if they didn't do it, because that would increase the overall possibility of me having to deal with another (sigh) semicolon-separated CSV file.

Reply on news.ycombinator.com