Hacker News Reader

Comment by andi999 | Hacker News Reader

Can you also set the decimal separator? Some countries use ',' in numbere like 10,5

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)

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.

Can we please, please, stop that? If we go Metric, will you please standardize on period as decimal point? Shake on it. Let's make it happen.

Somebody told me that the official international standard prefers comma; a period is just a permitted alternative. Of course, comma as decimal separator isn't very compatible with programming languages.

However, the decimal separator that I was taught at primary school and have used in handwriting all my life is neither comma, nor period, but '·'.

What, why? I've seen comma decimal separated values but I thought it was a weird English thing. What do these places use to separate larger values (e.g. each 10^3 magnitude increase) to make manual counting easier.

828.497.171.614,2?

https://en.wikipedia.org/wiki/Decimal_separator#Digit_groupi...

They use spaces or dots.

Exactly. The "official way" of writing big numbers around here (I know at least the balkans, germany and austria) is `1.000.000,00 €` (1 million). So what you wrote, but always at least 2 decimal places (or zero if it's not a financial document).

Doh, Having two opposite conventions is a PITA.

But if I add my 2 cents - I prefer 1,000.00 because I think it is similar to commas and full-stops in writing, where a comma is mainly a reading/speaking guide to help break up a sentence (or in this case a number) and a full stop is a much harder termination of a sentence (in the case of a number the official origin where int/non-fractional part ends).

You could argue that both ways. "Here's a big amount. That's a moderate amount. And that is a small amount, with a tiny extra bit." :)

What is worse is the ignorance on the English-speaking side. We have been putting up with your stuff for a few decades now, and almost the entire population needs to know about it, while we see near-zero attempts to adapt from your side.

I'd argue the decimal separator is more important and should therefore be more visible; the comma is larger than the dot and extends below the baseline so is easier to see.

Yes, using a dot for grouping is a common solution. But it seems to be fading out because of the conflict. Other solutions are a space (12 345,67) or apostrophe also known as "highcomma" (12'345,67).

Germany has been metric forever but has the comma as a decimal separator, and the dot as a thousands group separator. It’s deeply engrained in our typography, it has typographical idioms such as ,— (comma em-dash), up to the point that even brands have adopted it in their brand name.

I’m afraid we can’t really change that on a whim. Why would we, anyway?

" Why would we, anyway? "

To be compatible with the world, so Germans can use international software, and could sell software to international people.

Call me crazy, but I'm under the impression that Germans do use international software, and that Germany may even be home to the fourth largest software company in the world.

And in a largely successful attempt at German self-parody, that software is hugely complex and laborious; in short, over-engineered.

It is the only software I know of where you regularly hear of "implementation" -- which in this context means installing the software, not writing it -- projects being planned to take years, actually taking twice as long, and sometimes being abandoned altogether when the prospective client finds out it just can't be done.

I mean, it is SAP you're talking about, right?

America is not the world; at least in the western world[0] there are more countries and languages that follow the German convention. Also, there is more to the world than software (although that seems to be changing).

[0] Yes, that shows my limited perception.

There are more countries using the comma than the dot. Why should the majority follow a minority in that case?

Are you certain that more people, numerically speaking, use the comma as a decimal separator? India and China do not, although admittedly India has another decimal grouping system.

Yes, but does the number of people matter in that case?

If we are aiming to create a common international system of representing the fractional part of a decimal number, it makes sense to start with the system that is already in use by the most people.

No, it does not. The Countries individual choice has more weight than their number of citizens. It's probably also more work to change laws and regulations, than letting people adapt to the changes.

This is basically the classical problem of democratic systems, when they need to balance the interests of different sized groups. Numbers alone don't make a fair solution. And unless you have the power to force them, you will not convince everyone to follow you just by arguing with numbers anyway.

You are the one who proposed that the majority should not follow the minority, but now you are also saying that the minority should not follow the majority either. If your point is that nobody should follow anybody because freedom is more important than standardization, that's fine, but then it would have been clearer to just say that in the first place.

In my opinion, when we are talking about a data interchange format like CSV, having a simple, common format would be far more practical and efficient than allowing each country to decide for itself its own standard. Having dealt with exactly this problem in a global SaaS product where a minority of clients submitted CSV files with commas for decimal separators, I can say it would have made the parsing code a lot simpler and more robust if our system (and countless others like it) did not need to build in exceptions for this minority use case.

No. I agree it should be universally used for machine-readable data formats, but for human consumption there is no need to be anglo-centric.

You guys are already slowly encroaching on milliards and billiards in other languages with your illogical short scale numbers.

Don't worry, some of us are still fighting for the gloriously base-2 US customary system; base-10 is only for people who don't float. And the 30cm foot.

Well, in a way a base-2 system would have been far ahead of its time... it's not consistently base-2 though.

It is not a matter of what I use. It is a matter of what the data uses.

Reply on news.ycombinator.com