Open epicstar opened 22 hours ago
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.
Steps to reproduce
Link to live examples:
Steps (in live example):
DatePicker.format
to:M/D/YY
if usingdayjs
M/d/yy
if usingdate-fns
DatePicker
'sTextField
's date format to the library'sformat(date, fmt)
return string (see Demo.tsx)Current behavior
V5
Expected Behavior Happens
V7 - Bug Occurs
The
DatePicker
'sTextField
displays adds 1 extra 0 to single date months and days despite the date format specifically wanting single-digit months and days.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:
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 andd|D
's to the format when v5 strictly followed the given format.Your environment
``` 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) ```npx @mui/envinfo
Search keywords: date picker format