A document written in London, opened in Chicago and printed in Berlin can show three different versions of the same date and the same price. “03/04/2026” is the 3rd of April in one country and the 4th of March in another. A decimal comma and a decimal point swap places, and a thousands separator can look like a decimal point to a reader who expects the other convention. Exports take these choices away from the writer, so the editor has to decide them on purpose.
Store the value, format it on output
A date typed as text is ambiguous the moment it is saved. Store the date as an ISO value, such as 2026-04-03, and store the number as a plain number with no separators. Apply the display format only when the content is shown or exported. The stored value stays unambiguous, and the same document can be exported in two formats without changing the source.
const stored = { date: "2026-04-03", amount: 1234.5 };
// Show it the way the reader expects, using the locale of the export.
new Intl.DateTimeFormat("en-GB", { dateStyle: "long" }).format(new Date(stored.date));
// "3 April 2026"
new Intl.NumberFormat("de-DE", { style: "currency", currency: "EUR" }).format(stored.amount);
// "1.234,50 €"The two calls take their conventions from the locale string, not from the machine that runs them. Pass the locale the document is written for, or the one the reader chose, and never rely on the server’s default. A server in one country that formats dates for a reader in another is a common source of wrong invoices.
Ambiguous dates need a format the reader cannot misread
When a writer types a date by hand, the editor has to guess its format, or ask. A safe approach is to accept the common forms, convert them to ISO on save, and show the result in the document in a long form such as “3 April 2026”, which a reader in any country can read without thinking. Where the guess is uncertain, such as “03/04/2026”, show the interpreted date back to the writer before it is stored.
PDF exports fix the appearance, not the meaning
A PDF keeps the formatted text, so the reader sees exactly what the export produced. That is useful for a final document, but it also freezes any mistake. If a date was formatted in the wrong locale on export, the wrong date is now permanent in the PDF. Format at export time with the locale the reader expects, and keep the ISO value in the source so the document can be re-exported correctly.
A spreadsheet export needs numbers as numbers
A value exported as the text “1.234,50” will not sum in a spreadsheet whose locale expects a decimal point. Export numeric cells as numbers, and let the spreadsheet apply its own format. Dates work the same way: write them as date values, not as formatted strings, so the spreadsheet can sort and calculate with them. The exact cell type depends on the export format, so test each one.
A short test list
- Export a document with a date of 3 April 2026 in English and German locales. Both should show the right day.
- Type 03/04/2026 by hand and confirm the editor shows the interpreted date before saving.
- Export a price with a decimal and check the separators match the reader’s locale.
- Open a spreadsheet export and sum a column of exported numbers. The total should match the document.
- Re-export a saved document a year later and confirm the dates have not shifted.
RichTextEditor is a perpetual-licence JavaScript editor — one purchase, self-hosted, no metered editor loads. Download the evaluation or see how it compares.