Why not use the locale of the system that produced the file?

Because the file does not state it, and a locale inferred from where a vendor is headquartered is a guess wearing a justification.

What proves the format?

A row the format itself disambiguates, such as a day part above twelve, read from the same column as the ambiguous rows.

What happens if nothing proves it?

The build stops and says which column and which rows were ambiguous, because publishing under a guessed locale is authoring a number.

Failure catalogue · The file lies · 10 of 51

OBSERVED FAILURE MODE

The date that parses two valid ways.

4/9/2026 is April 9th or September 4th depending on a locale the file never states, and both parses succeed, so nothing errors and nothing warns. A column of them lands in whichever set of months the tooling prefers, and every total, trend, and period heading downstream inherits that preference silently.

What we saw

A campaign export at Meridian Journal Group carried dates written as 4/9/2026, with no locale stated anywhere in the file or in its documentation. Read one way the rows fell in April, read the other they fell in September, and both readings parsed without complaint. The file did settle it, but only in the rows nobody had looked at: a handful of dates whose day part exceeded twelve, which can be read one way alone and which prove the format for every ambiguous row beside them. Nothing in the build had gone looking.

Why it passes a glance

A parser that succeeds looks like a parser that is right. There is no exception, no null, and no red row: every value becomes a date, and the totals under them tie whichever way the months fell. A month-over-month chart drawn from the wrong reading is smooth and plausible, and the only readers who can see the error are those who already know what the period should look like.

What addresses it

Doctrine principle 3, refuse to guess, treats a date that parses two valid ways as exactly as much an error as one that parses none: prove the format from rows the file itself disambiguates, apply the proof to the ambiguous rows, disclose the proof on the page, and stop when nothing settles it. The period-freshness skill routes that stop through the refusal writer, so an unprovable date produces a blocked report carrying every verdict the surviving rows earned.

Check your own file in two minutes

Scan your date column for any value whose first part exceeds twelve, since it can be read one way only.
Use those rows to fix the format, apply it to the whole column, and print the proof beside the period heading.
If no row in the column settles the format, stop and ask the vendor rather than accepting whichever reading your tooling defaults to.

What this does not catch

The proof settles the format for the file in front of you. The next export from the same system can change dialect without warning, and a column in which every day part is twelve or lower offers nothing to prove the format from at all.

Quick answers

Why not use the locale of the system that produced the file?: Because the file does not state it, and a locale inferred from where a vendor is headquartered is a guess wearing a justification.
What proves the format?: A row the format itself disambiguates, such as a day part above twelve, read from the same column as the ambiguous rows.
What happens if nothing proves it?: The build stops and says which column and which rows were ambiguous, because publishing under a guessed locale is authoring a number.

Nearby failures

Two date formats in one columnThe file lies The filename that lies about the periodThe file lies The stack trace deliverableThe wrapper betrays the numbers

Last updated 2026-09-02 · Dylan, founder · one of 51 observed failure modes, every one seen in a real build or in our own audits, none invented.

Get the free skill → The doctrine All 51 failure modes