Modernizing AWK, a 45-year old language, by adding CSV support

Re:Modernizing AWK, a 45-year old language, by adding CSV su... by otikik on Thursday May 12, 2022 @12:15PM (#31356232)

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)

[ Parent | on HN ]

Re:Modernizing AWK, a 45-year old language, by adding CSV su... by hedora on Thursday May 12, 2022 @12:34PM (#31356460)

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!)

[ Parent | on HN ]

Re:Modernizing AWK, a 45-year old language, by adding CSV su... by j0057 on Thursday May 12, 2022 @04:19PM (#31359689)

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!

[ Parent | on HN ]

Re:Modernizing AWK, a 45-year old language, by adding CSV su... by denisw on Thursday May 12, 2022 @04:51PM (#31360005)

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

[ Parent | on HN ]

Re:Modernizing AWK, a 45-year old language, by adding CSV su... by andi999 on Thursday May 12, 2022 @03:54PM (#31359428)

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?

[ Parent | on HN ]

Re:Modernizing AWK, a 45-year old language, by adding CSV su... by otikik on Thursday May 12, 2022 @07:20PM (#31361271)

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.

[ Parent | on HN ]