The export said 03/04/2025. Your colleague's Excel read March 4th; yours read April 3rd; a third machine turned the product code 1-5 into January 5th. Nobody edited anything — Excel just guessed, differently, everywhere. Here's how dates survive CSV.
03/04/2025 is genuinely ambiguous — US convention says March 4, most of the world says April 3. Excel resolves it with your machine's locale, silently, and writes its interpretation back when you save.
It's eager, too: anything date-shaped converts. 1-5, MAR1, 1.2.3 — codes like these become dates so often that geneticists literally renamed human genes because Excel kept converting them.
2025-03-04 (year-month-day) has one reading everywhere — no locale can flip it, and as a bonus it sorts correctly as plain text. Every serious data system speaks it.
If you control the export, choose ISO dates and this whole class of bug disappears. If you don't, normalize the file before anyone's Excel touches it.
Data → From Text/CSV lets you set a column's type to Date with an explicit source format — or to Text if it isn't a date at all (those product codes). Once the format is pinned, locale stops mattering.
For files you only need to read, skip Excel: a non-coercing viewer shows the dates exactly as exported.
When two people see different dates, settle it at the byte level: open the raw file. If the source is ambiguous (03/04/2025), only the exporting system knows the intent — get the rule from there, then normalize to ISO so the question never comes back.
The date normalizer shows you its interpretation per column before converting, so a wrong guess is visible instead of silent.
SKUs like 1-5, versions like 1.2.3, references like FEB10 — import these as Text, or ship a typed .xlsx where they're already text cells so downstream Excels can't touch them.
If a column of codes was already converted, the original strings are usually gone from that file — like rounded IDs, recovery means the source export.
ISO 8601: 2025-03-04, with times as 2025-03-04T15:30:00Z. Unambiguous in every locale, sorts as text, parsed by everything.
A workbook crossed the old Mac/Windows epoch boundary (1900 vs 1904 date systems). It's a spreadsheet serial-number issue, not a CSV one — re-export with the correct date system, then normalize to ISO.
Not from that value alone. Look for a day greater than 12 anywhere in the column (13/04 can only be day-first) — the normalizer uses exactly that signal; otherwise confirm with the source system.
Date eagerness: digit-dash-digit parses as day-month. Import the column as Text, or deliver a typed workbook so the guess never runs.