[Date Picker] DatePicker improperly adds extra 0's on Single-Digit Months and Days; It Should Strictly Respect Given Date Format

[epicstar]

Steps to reproduce

Link to live examples:

• dayjs sample code
• date-fns sample code

Steps (in live example):

1. Set DatePicker.format to:
   1. M/D/YY if using dayjs
   2. M/d/yy if using date-fns
2. In the date picker, select a date with a single digit month and day
3. Compare the DatePicker's TextField's date format to the library's format(date, fmt) return string (see Demo.tsx)

Current behavior

V5

Expected Behavior Happens

V7 - Bug Occurs

The DatePicker's TextField displays adds 1 extra 0 to single date months and days despite the date format specifically wanting single-digit months and days.

const fmt = "M/D/YY";

export default function FirstComponent() {
  const [date, setDate] = React.useState(dayjs());
  return (
    <LocalizationProvider dateAdapter={AdapterDayjs}>
      <DatePicker
        format={fmt}
        value={date}
        onChange={(newDate) => {
          setDate(newDate);
        }}
        slotProps={{
          toolbar: {
            toolbarFormat: fmt,
          },
        }}
      />
      <Box>{date?.format(fmt) ?? "Please select date"}</Box>
      <Box>
        If formatted date is not the same, there is a bug in the DatePicker.
      </Box>
    </LocalizationProvider>
  );

Expected behavior

The given format to the TextField should be the same as the library's format(date, fmt) call. This was the case in v5 of the Date Picker library.

Context

In most cases of our frontend (not all), we expected all our date formats to follow the following pattern:

1. single digit months should just display the month number with no extra zeroes
2. single digit days should just display the day number with no extra zeroes

We're doing this for mostly... reasons (keeps the text field compact etc.).

When updating from v5 to v7 (skipped v6), we noticed our date pickers have added zeroes to single digit days or months regardless of the given date format. The format seems to be followed as expected except for the single digit case I can't figure out a reason why the format is changed such that we are adding extra M's and d|D's to the format when v5 strictly followed the given format.

Your environment

npx @mui/envinfo

  System:
    OS: Windows 11 10.0.22631
  Binaries:
    Node: 20.16.0 - ~\AppData\Local\Temp\xfs-af08357a\node.CMD
    npm: 9.6.7 - C:\Program Files\nodejs\npm.CMD
    pnpm: Not Found
    yarn: 4.5.0 (this is what we use)
  Browsers:
    Chrome: 128.0.6613.139 (Official Build) (64-bit)
    Edge: Chromium (127.0.2651.74)

Search keywords: date picker format

[flaviendelangle]

Hi,

The behavior around leading zeroes is explained in this doc section

You can enforce it, but this comes with some tradeoffs if you try to access the value directly on the DOM element or if you are using form submission.
With v8 and moving forward we should be able to improve this behavior thanks to a new DOM structure that do no longer have these limitations.

[epicstar]

[...] comes with some tradeoffs if you try to access the value directly on the DOM element or if you are using form submission.

Can you please explain the tradeoffs?

The only reason why I thought this was a bug is because I didn't see anything about this in the migration guide.... Thank you.

[flaviendelangle]

I linked you the doc section for the full context.

But to summarize, if we don't have a leading zero, there are some situations where we need to add a hidden character in your input to make sure onChange is being called (other wise if you select a section where the month is 1 and you press 1, onChange is not fired by the browser because the value did not change).
And this hidden character is something that can cause problem if you want to access your value in tests or if you are using form submission instead of our onChange prop.

[epicstar]

Ok... thank you guys. (Hopefully this is added to the migration docs).

[github-actions]

This issue has been closed. If you have a similar problem but not exactly the same, please open a new issue.
Now, if you have additional information related to this issue or things that could help future readers, feel free to leave a comment.

Note

We value your feedback @epicstar! How was your experience with our support team?
We'd love to hear your thoughts in this brief Support Satisfaction survey. Your insights help us improve!