[pickers] Some LocalizationProvider dateFormats are barely used

[mspiess]

Steps to reproduce

Steps:

1. Open this link to live example: https://stackblitz.com/edit/react-geauqbih?file=Demo.tsx
2. Pick a date

Current behavior

The date is displayed in the default format, e.g. 01/08/2025 12:00 AM.

Expected behavior

The date should be displayed in the keyboardDateTime format: 01.08.2025 | 12:00

Context

I'm trying to change the format for all DateTimePickers given a certain locale.
This could be achieved through the format prop on the DateTimePicker component, but that would have to be set on every component.
The dateFormats seem to exist to solve this very problem, but many (fullTime & keyboardDateTime + 12h/24h variants on each) seem to be unused beside outside some aria- labels,
This is despite their jsdoc claiming "Used in the date-time fields".

Your environment

npx @mui/envinfo

System:
    OS: Windows 10 10.0.19045
  Binaries:
    Node: 20.12.1 - C:\Program Files\nodejs\node.EXE
    npm: 10.5.1 - C:\Program Files\nodejs\npm.CMD
    pnpm: Not Found
  Browsers:
    Chrome: Not Found
    Edge: Chromium (130.0.2849.68)
  npmPackages:
    @emotion/react: ^11.13.3 => 11.13.3
    @emotion/styled: ^11.13.0 => 11.13.0
    @mui/core-downloads-tracker:  6.4.1
    @mui/icons-material: ^6.1.6 => 6.1.6
    @mui/material: ^6.1.6 => 6.4.1
    @mui/private-theming:  6.4.1
    @mui/styled-engine:  6.4.0
    @mui/system:  6.4.1
    @mui/types:  7.2.21
    @mui/utils:  6.4.1
    @mui/x-data-grid:  7.22.1
    @mui/x-data-grid-premium: ^7.22.1 => 7.22.1
    @mui/x-data-grid-pro:  7.22.1
    @mui/x-date-pickers: ^7.22.1 => 7.22.1
    @mui/x-internals:  7.21.0
    @mui/x-license:  7.21.0
    @types/react: ^18.3.12 => 18.3.12
    react: ^18.3.1 => 18.3.1
    react-dom: ^18.3.1 => 18.3.1
    typescript: ^5.6.3 => 5.6.3

Search keywords: dateFormats AdapterFormats keyboardDateTime

[mspiess]

useUtils can be useful for a workaround, but it's internal and still has to be set on every date picker:

import * as React from 'react';
import { AdapterDayjs } from '@mui/x-date-pickers/AdapterDayjs';
import { LocalizationProvider } from '@mui/x-date-pickers/LocalizationProvider';
import { DateTimePicker } from '@mui/x-date-pickers/DateTimePicker';
import { useUtils } from '@mui/x-date-pickers/internals';

function FormattedDatePicker() {
  const { formats } = useUtils();
  return <DateTimePicker format={formats.keyboardDateTime} />
}

export default function FirstComponent() {
  return (
    <LocalizationProvider
      dateAdapter={AdapterDayjs}
      dateFormats={{ keyboardDateTime: 'DD.MM.YYYY | HH:mm' }}
    >
      <FormattedDatePicker />
    </LocalizationProvider>
  );
}

[LukasTy]

Hello @mspiess
Thank you for creating this issue and bringing this problem to light. 🙏
There are some inconsistencies that we need to address.
This demo shows the inconsistency and the problem.

• The keyboardDateTime format is never used internally, because we use keyboardDateTime12h or keyboardDateTime24h, based on the value of the ampm flag.
  This format can be removed.
• DateTimeField uses the set dateFormat, whereas the Picker component ignores this value, because it resolves the format programmatically, based on the provided views:
  

  mui-x/packages/x-date-pickers/src/internals/utils/date-time-utils.ts

  Line 14 in f5f7505

  export const resolveDateTimeFormat = (

  
  We need to bring clarity to this difference of behavior, or consider if the added extra logic of resolving the format, based on views is worth the added complexity and edge cases. 🙈
  More often than not, having only one way to do a certain thing is easier to reason about and has the least amount of bugs/edge cases.

I'm adding the issue to our grooming board for the team to find the best solution. 😉

[LukasTy]

Hello again @mspiess.
We have agreed to remove the formats that are not being used.
As for the case with the Pickers format resolving on the Date Time Picker, we feel it makes sense, given the component's behavior.
If we directly use the keyboardDateTime format, it could cause various issues where you might have a certain view, but a section for that view does not exist due to the format. 🙈

We are not very fond of the dateFormats prop on the LocalizationProvider as it lacks clarity of what it will change.

Have you considered using defaultProps in the theme to override the format on all the Picker usages?

const theme = createTheme({
  components: {
    MuiDateTimePicker: {
      defaultProps: {
        format: 'DD.MM.YYYY | HH:mm'
      }
    }
  }
});

[mspiess]

Hello @LukasTy,
thanks for the detailed response.

If we directly use the keyboardDateTime format, it could cause various issues where you might have a certain view, but a section for that view does not exist due to the format.

I feel like that issue could be elegantly solved, if the dateFormats were allowed to reference their respective "subformats" somehow.
Then users could provide formats to override the combining template strings such as:

• https://github.com/mui/mui-x/blob/f5f750567470094bcd21e301aca3a8438aa6865e/packages/x-date-pickers/src/internals/utils/date-time-utils.ts#L55C10-L55C39
• https://github.com/mui/mui-x/blob/22f070e3d5ef6261c4001573894098d17c280f6e/packages/x-date-pickers/src/internals/utils/date-utils.ts#L181C12-L181C46
• https://github.com/mui/mui-x/blob/22f070e3d5ef6261c4001573894098d17c280f6e/packages/x-date-pickers/src/internals/utils/date-utils.ts#L185C12-L185C52

Have you considered using defaultProps in the theme to override the format on all the Picker usages?

Not yet. I'm not sure if that's feasible, given that the theme would have to be re-created whenever the locale changes.