Number formatting, locale conventions and display vs storage
Numbers that look simple are a persistent source of bugs at locale boundaries. The number 1,234.56 means one thousand two hundred thirty-four point five six in the US, UK, and most of Asia. In Germany, France, Brazil, and most of continental Europe, the exact same digits written as 1.234,56 carry the same meaning, the comma is the decimal separator and the period is the thousands separator. A value like 1,234 is unambiguous in the US (one thousand two hundred thirty-four) but ambiguous in a European context (could be one point two three four). Data pipelines that import CSV files from mixed locales silently corrupt numeric values unless they explicitly specify the locale of the source file.
| Locale | Example | Decimal sep. | Thousands sep. |
|---|---|---|---|
| US, UK, AU | 1,234,567.89 | . | , |
| DE, FR, BR | 1.234.567,89 | , | . |
| CH (Swiss) | 1'234'567.89 | . | ' (apostrophe) |
| IN (India) | 12,34,567.89 | . | , (lakh grouping) |
| ISO 31-0 | 1 234 567.89 | . | Space |
Currency, percentages, and significant figures
Currency formatting adds the currency symbol in the position appropriate for the locale ($1,234.56 but 1.234,56 €), and may require specific decimal precision (most currencies use 2 decimal places; some like JPY use 0; cryptocurrency uses 8+). Financial applications must use exact decimal arithmetic for currency, floating-point arithmetic (0.1 + 0.2 in JavaScript returns 0.30000000000000004) is unsuitable for money. For scientific data, formatting to significant figures (3 sig figs: 1,234,567 → 1,230,000; 0.0012345 → 0.00123) is more meaningful than a fixed decimal count.
Related: CSV viewer for tabular numeric data, JSON formatter for API numeric values.