[pickers] Remove reference of fields having dependant section behavior

[Martin-Cox]

Duplicates

• I have searched the existing issues

Latest version

• I have tested the latest version

Steps to reproduce 🕹

Link to live example: https://mui.com/x/react-date-pickers/date-time-picker/#basic-usage (direct link: https://codesandbox.io/s/1m7pyd?file=/demo.tsx)

Steps:

1. Open the "Basic usage" demo for the v6 DateTimePicker
2. Enter the date/time "02/28/2023 01:01 AM" (28th February 2023)
3. Select the "day" component (28)
4. Press the Up arrow key to increment the day

Current behavior 😯

The date "resets" back to the 01st of February instead of rolling over to the 01st of March

Expected behavior 🤔

The date should roll over to the 01st of March

Context 🔦

The announcement for the v6 date/time pickers demonstrates this date/time "rollover" functionality. If you enter the same date into the demo field as in the reproduction steps and hit the Up arrow key the date changes to 01st March, instead of resetting back to the 01st February.

https://mui.com/blog/v6-beta-pickers/#enhanced-keyboard-usability
https://codesandbox.io/s/date-field-demo-pb87v0?from-embed=&file=/demo.tsx:32-112

[LukasTy]

Thank you for opening this issue.
We recently changed this behavior.
The independent behavior is more correct compared to native date picker component implementations as well as from an accessibility point of view.

We'll update the blog entry to avoid this information discrepancy. 😉

[Martin-Cox]

Ah that's a shame, it was something we were hoping to use. One of the complaints with our current usage of the native Chrome date/time picker is that it doesn't rollover the dates, as users expect it behave like a calendar.

Is there a possibility this could ever return via an option? Other date/time pickers (e.g. Kendo UI) have this functionality https://demos.telerik.com/kendo-ui/datetimepicker/index

[LukasTy]

Is there a possibility this could ever return via an option?

We did consider it initially, but went for the independent approach, because of the mentioned reasons as well as the fact that it allowed us to clean up the code quite a bit.
We would consider bringing it back as an option if there is a high enough demand for it, but in essence, it's not the best approach considering the a11y implications it brings.

The fields have quite a lot of ways to change a value (number keys, arrow navigation, Page Up, PageDown, Home, End). Because of this reason, we feel that the drawbacks that having this behavior, would bring are not worth it.