No way to define default region settings

There isn't a way to define the region settings for the application. It appears to be using en-US region settings by default with options to change the currency to several main types. But there isn't a way to define the region settings for the overall application so defaults to currency and, in particular, dates are applied so a US date is current stored in the field as an integer, even when typed in a "dd/mm/yyyy" or "dd-mm-yyyy" format, while a non-US format date, such as "25/09/2026", appears to be stored as text.

US Date example

Non-US date example

Regional formats and date input per region are covered by the open PR #191 (adds a separate regional-format setting next to the interface language; typed dates and numbers are parsed per region, files stay en-US internally, default stays en-US). It lists en-US, de-DE, fr-FR, es-ES, it-IT, pt-BR, pt-PT, ru-RU, ja-JP, ko-KR, zh-CN and zh-TW. Not in it as far as I can see: en-GB (D/M/Y) and en-IN (lakh grouping). Those can follow as small region additions once #191 is merged.

#447 adds File › Options › Regional format (15 regions, including en-GB and en-IN). Typed dates and numbers, and how they are shown, follow it: 25/09/2026 in en-GB, 1,23,456.50 in en-IN, 1.234,56 and 15.03.2026 in de-DE. On first run it follows the system region. Stored values and files are unchanged, so switching back shows the same cells in the old layout.

Adding a CSV-import repro for the same problem, with gridcraft-cli 0.5.0 (macOS universal, release v0.5.0). #447 keeps CSV import in en-US, and the regional CSV PR mentioned in #191 isn't merged yet, so this is what users get today when they open a Spanish bank export. The same happens in the app's File ▸ Open of a .csv.

Repro (save as es.csv, UTF-8):

Fecha;Concepto;Importe
05/10/2026;Alquiler;-1.234,56
25/08/2026;Nómina;2.500,00
01/02/2026;Café;-3,5

gridcraft-cli eval '=MONTH(A2)'   --in es.csv   # → 5   (expected 10: 5 October 2026)
gridcraft-cli eval '=ISTEXT(A3)'  --in es.csv   # → TRUE (25/08/2026 is kept as text)
gridcraft-cli eval '=ISTEXT(C2)'  --in es.csv   # → TRUE (-1.234,56 is kept as text)

The same happens with a comma separator and quoted fields. Setting LANG=es_ES.UTF-8 or a Spanish system region changes nothing. file.open, data.fromTextCsv and data.textToColumns have no date-order or decimal-separator parameter. In a 40-row file, 16 dates were silently stored as the wrong date and 24 as text.

Why it matters: in Spain and most of Europe, bank statements and exports look exactly like this. Opening them gives wrong dates and non-numeric amounts. Sorting, SUM and pivots then give wrong answers, nothing warns the user, and saving writes the damage back.

Asks for the CSV part:

An import option, like the column data format «Date: DMY» and the decimal and thousands separators of Excel's Text Import Wizard. For example: data.fromTextCsv {path, delimiter, dateOrder: "dmy"|"mdy"|"ymd", decimalSeparator: ",", thousandsSeparator: "."}, the same keys on file.open for .csv, and --locale / --date-order / --decimal on gridcraft-cli convert and run --in. The CLI and MCP currently stay en-US even after M12: regional formats (typed and displayed numbers, dates and times) #447.
A default taken from the regional format setting of M12: regional formats (typed and displayed numbers, dates and times) #447 or the system region, with the canonical formula syntax unchanged.
When a column mixes parsed dates and unparsed date-like text, a warning (stderr in the CLI, a notice in the app) instead of silently mixing types.

Workaround we use today: convert the CSV to ISO dates and dot decimals before opening it. After that GridCraft reads it correctly (MONTH → 10, SUM exact).

@acroberts88

@acroberts88 thanks for the repro. You're right that #447 leaves this as it is: read_csv (crates/xlsx/src/csv.rs) still calls the en-US parse_input, and so does #447. That's on purpose, so that #447 doesn't change what scripts get from a file. The regional CSV PR is the next one after #447. Here is how it lines up with your asks:

Import option. file.open for .csv/.txt and data.fromTextCsv take region: "es-ES", the convention M12: regional formats (typed and displayed numbers, dates and times) #447 already uses for every command that accepts typed text. It covers your three cases: 05/10/2026 as 5 October, 25/08/2026 as a date, -1.234,56 as a number. Explicit dateOrder, decimalSeparator and thousandsSeparator overrides would cover the Text Import Wizard's separate settings, for exports whose dates and numbers don't follow one region. The CLI gets --region on convert and run --in.
Default. File › Open in the app uses the Regional format setting, which starts from the system region, as Excel does with a double-clicked CSV. Commands without region stay en-US. M12: regional formats (typed and displayed numbers, dates and times) #447 kept that rule after its review found that following the session's preference made the same script store different values depending on the machine. So the CLI and MCP read regionally only when asked.
Warning on mixed columns. Excel doesn't warn there; it keeps the text silently. That would go beyond Excel, so it's the maintainers' call, and I'd keep it out of that PR.

Saving is half done: #427 keeps the list separator the file was opened with, but numbers and dates are still written in en-US (-1234.56, 10/5/2026). The same PR writes them in the file's region, so a Spanish export saves back as -1.234,56 and 05/10/2026.

From #1141: pt-BR expects R$ 1.234,56, -R$ 50,00, dd/mm/aaaa and 1.234,56 typed as a number; in Excel for Mac (es-MX) stored codes stay en-US (m/d/yy) and only the display follows the region. From #1751: on gridcraft-cli 0.8.0 (it_IT) typed 7,1 is stored as text and =A1*2 gives #VALUE! with no warning; Windows 11 0.7.0 does not detect it-IT. From #1130: a file made in current Excel shows all dates as MM/DD/YYYY. From #857: Currency/Accounting default to $. From #1071: no nl-NL region in #447. Also requested: de-DE (#1142), da-DK (#1859), decimal comma on the numeric keypad (#1640).

Navigation Menu

Repository navigation

No way to define default region settings #361

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

No way to define default region settings #361

Description

Activity

vangel76 commented on Oct 11, 2026

quantmind-br commented on Oct 11, 2026

acroberts88 commented on Oct 12, 2026

quantmind-br commented on Oct 12, 2026

aiongg commented on Oct 19, 2026

aiongg commented on Oct 19, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions