Date filters: Date style is ignored when a date is displayed, typed, and may silently return a different date

Describe the bug

Dates typed into a dashboard date filter are not read using the instance's Date style setting. The inputs accepts formats of their own, and unless the configured style happens to coincide with one of them, users may silently end up with a date they didn't type.

How dates work today

1. Everywhere in Metabase (tables, dashboards, and the date filter's own buttons showing the currently selected date) dates are displayed according to Date style plus Language. Date style sets the structure (which component comes first, separators), and Language supplies the words, so a spelled-out month appears in the interface language.

2. In the date filter's inputs, the displayed date ignores Date style and follows Language only. It is always the long written form with the month spelled out: September 17, 2026 in English, 17 septembre 2026 in French, 2026. szeptember 17. in Hungarian. So a filter shows dates in two different formats: its button label in the configured Date style, and when focused, its input box in a localized long form.

3. When a date is typed, it is read in two attempts, neither of which involves Date style:

   • First, as that same long written form for the current Language. This match is not strict, so a near-miss can produce a wrong date instead of failing.
   • If that fails, the text is handed to JavaScript's built-in date parser — the Date constructor, new Date(text).

Beyond ISO YYYY-MM-DD, its behavior is implementation-defined per the ECMAScript spec, so it is the browser's own lenient legacy parser: in Chromium it reads numeric dates month before day and accepts many partial strings. Results can differ between browsers.

1. The text is re-read on every keystroke, and when the field loses focus it corrects itself to the last value it managed to understand. So if the finished text can't be read, an earlier fragment wins — typically the first character, where a lone digit is read as a month in a default year of 2001.

Notable error modes

Which of these an instance hits depends on how its configured Date style relates to the formats the inputs accept. Taking one configured style as an example — Date style set to 31/12/2018, Language English:

• Day and month silently swapped. Typing 03/01/2026, meaning 3 January, gives 1 March 2026. This happens whenever both numbers are 12 or less.

• Replaced by an unrelated date. Typing 28/08/2026 gives 1 February 2001; 13/01/2026 gives 1 January 2001. This is the fragment-wins behavior from point 4.

• The accepted format is not the configured one. Typing 08/28/2026 works, although nothing in the instance displays dates that way.

• A near-miss of the displayed form gives a wrong date. Typing 28 August 2026 gives 8 August 2026. The non-strict match in point 3 half-succeeds, and because it "succeeded", the fallback that would have read it correctly never runs.

• The dashboard button and the picker inputs disagree for the same value. After applying a range, the filter button on the dashboard reads 28/8/2026 - 3/9/2026, but reopening the picker shows August 28, 2026 in the input for that identical date.

• What does work, though neither is discoverable: ISO format 2026-08-28, and the long localized form exactly as the field itself displays it (August 28, 2026 in English, 2026. augusztus 28. in Hungarian).

To Reproduce

Just a single error mode: a date typed in the Date style is replaced by an unrelated date.

1. Go to Admin → Settings → Localization and set Date style to 31/12/2018.
2. Create a dashboard with any question on Sample Database → Orders.
3. Add a "Date picker" filter of type "Date range", connect it to Created At, and save.
4. Open the filter and click into the "Start date" input.
5. Clear the field, type 28/08/2026, then press Tab.

Result: date filter reads February 2001. No error is shown.

Expected: the field reads 28 August 2026.

Expected behavior

• Dates typed into the filter should be read using the instance's Date style setting.
• The inputs should ideally also display dates in that style, so that what users see and what they can type agree with the rest of the instance.
• Input that can't be read should be rejected rather than silently replaced by a different date.

Logs

n/a

Information about your Metabase installation

Reported on **v1.57.5.5**, reproduced on: **v1.57.20**, **v1.58.31** and **v1.63.17**.

Severity

Reported by Pro customer. Filters returning unintended may result in incorrect results

Additional context

Related

• [#61649](https://github.com/metabase/metabase/issues/61649, FR): Date style not applied to the date picker. It covers display, while this report is about typed input being misread.
• #59829: date filter localization regressions.