Spreadsheet locale bugs: dates, decimal separators, and leading zeros

A numeric cell can display as a date, percentage, currency, or plain number depending on its format. Changing the display does not necessarily change the underlying value, while parsing imported text can change the value itself. Record which transformations the workflow performs: opening an existing workbook, importing CSV, copying text, recalculating formulas, or exporting to another format. These operations have different risks. Verify date system handling using the selected spreadsheet engine's documentation, particularly when workbooks originate from environments with different date system settings.

The string 03/04/2026 can mean different calendar dates in different locales. A value such as 1,234 may be interpreted as a grouped integer or a decimal value depending on parsing rules. For structured imports, prefer an explicit schema and a declared locale. Where the interface accepts ambiguous text, show a preview of the parsed result before committing large changes. Do not infer the desired convention solely from browser language if the business dataset uses a fixed regional standard independent of the user's personal preferences.

Give a bulk import a typed schema where possible. If the source has no schema, show a preview that makes the parsed value visible alongside the original string. A display format applied after an incorrect parse can conceal the mistake rather than repair it.

For exported data, document the convention the receiver should use. A CSV does not carry the same formatting and type information as a workbook. Even a carefully exported identifier may be auto-converted by the next application. Include a field specification or choose a structured transfer format when exact types are essential. Test the real receiving application rather than checking only that the generated text contains the expected characters.