3 ms·

For me, it was a pita when converting database numeric values to JSON numbers given different regional settings on the server.

by ak39 7y ago

cehrlich 7y ago
Sure, but that just means it's annoying that there's two different arbitrary standards, not that one is better than the other.
scbrg 7y ago
Of course. When you're working mainly with one format, the other becomes a hassle. The point is that those two formats are pretty much equivalent, quality wise. One is not inherently better or worse than the other. When it comes to imperial vs. metric, the systems are very much not equivalent, and you could argue that either of them is better. Of course, they're better at different things, so in the end it comes down to weighing their respecting strengths against each other - but at least there the discussion is somewhat meaningful. When it comes to dot vs comma, it's just an arbitrary choice, and too bad we didn't all choose the same.
jeroenhd 7y ago
I agree, it's quite annoying to see American style numbering everywhere. An Intel driver program crashed at me because it stored its Window size American style while the system was set to a different locale. This can easily be fixed by specifying the input and output locale in your code, which I'd something you should always do anyway if you're selling software to more than one country. There's more differences in internationalisation than just decimal separators and date formats. Using proper locale code will fix all of those for you so you don't have to deal with calls from customers.
- CydeWeys 7y ago
  JSON (and CSV for that matter) both use commas as list/column separators. So formatting floats using periods as the separator is much more compatible with these formats. Never mind that programming languages format their floats in this manner too. Let's not kid ourselves, the comma representation does not play well with programming languages or common data formats, and for that reason shouldn't be used except at the very top level of the UI for formatting purposes when displaying for certain locales. You're needlessly making things a lot harder for yourself if you attempt otherwise.
  - jeroenhd 7y ago
    Most of the CSVs I've encountered used the semicolon as a field separator, probably for exactly this reason, even ones from American sources. JSON has a standard format for writing numbers, which happens to be the American one, and I don't know what other data formats are sensitive to the comma. I don't store floats in the users locale and I don't think anyone should, just like dates should be stored in UTC (timestamps, preferably) instead of in any local date format. However, many programmers seem to forget that if you don't specify a locale, the system will choose one for you and its probably the one the user set up while installing their system, just like what would happen with any date or time. I'm not going to change the way I write numbers because some American programmer thinks it's too annoying to bother and neither are my customers. Localisation is important to remember because if you don't, you're going to be burned by it at some point. This is just another gentle reminder about that.
- renaudg 7y ago
  Other similar annoyances in US-centric front-end JS code : - Numeric text fields filtering out all characters except figures + ".", even when the locale is set to something that should allow commas. - Numeric text fields that expect a specific keyboard layout, for example numbers as the lower characters of the top keyboard row, filtering out anything else. In some layouts (like French), that's not the case : numbers on the top row are accessed with Shift, direct access is for symbols / punctuation. If the text field also disallows pasting, that makes it impossible to fill unless you switch layouts in the OS.

For me, it was a pita when converting database numeric values to JSON numbers given different regional settings on the server.

by ak39 7y ago

For me, it was a pita when converting database numeric values to JSON numbers given different regional settings on the server.

cehrlich 7y ago

Sure, but that just means it's annoying that there's two different arbitrary standards, not that one is better than the other.

scbrg 7y ago

Of course. When you're working mainly with one format, the other becomes a hassle. The point is that those two formats are pretty much equivalent, quality wise. One is not inherently better or worse than the other. When it comes to imperial vs. metric, the systems are very much not equivalent, and you could argue that either of them is better. Of course, they're better at different things, so in the end it comes down to weighing their respecting strengths against each other - but at least there the discussion is somewhat meaningful. When it comes to dot vs comma, it's just an arbitrary choice, and too bad we didn't all choose the same.

jeroenhd 7y ago

I agree, it's quite annoying to see American style numbering everywhere. An Intel driver program crashed at me because it stored its Window size American style while the system was set to a different locale. This can easily be fixed by specifying the input and output locale in your code, which I'd something you should always do anyway if you're selling software to more than one country. There's more differences in internationalisation than just decimal separators and date formats. Using proper locale code will fix all of those for you so you don't have to deal with calls from customers.

CydeWeys 7y ago
JSON (and CSV for that matter) both use commas as list/column separators. So formatting floats using periods as the separator is much more compatible with these formats. Never mind that programming languages format their floats in this manner too. Let's not kid ourselves, the comma representation does not play well with programming languages or common data formats, and for that reason shouldn't be used except at the very top level of the UI for formatting purposes when displaying for certain locales. You're needlessly making things a lot harder for yourself if you attempt otherwise.
- jeroenhd 7y ago
  Most of the CSVs I've encountered used the semicolon as a field separator, probably for exactly this reason, even ones from American sources. JSON has a standard format for writing numbers, which happens to be the American one, and I don't know what other data formats are sensitive to the comma. I don't store floats in the users locale and I don't think anyone should, just like dates should be stored in UTC (timestamps, preferably) instead of in any local date format. However, many programmers seem to forget that if you don't specify a locale, the system will choose one for you and its probably the one the user set up while installing their system, just like what would happen with any date or time. I'm not going to change the way I write numbers because some American programmer thinks it's too annoying to bother and neither are my customers. Localisation is important to remember because if you don't, you're going to be burned by it at some point. This is just another gentle reminder about that.
renaudg 7y ago
Other similar annoyances in US-centric front-end JS code : - Numeric text fields filtering out all characters except figures + ".", even when the locale is set to something that should allow commas. - Numeric text fields that expect a specific keyboard layout, for example numbers as the lower characters of the top keyboard row, filtering out anything else. In some layouts (like French), that's not the case : numbers on the top row are accessed with Shift, direct access is for symbols / punctuation. If the text field also disallows pasting, that makes it impossible to fill unless you switch layouts in the OS.