[pickers][MobileDateTimeRangePicker] Issues combining with renderTimeViewClock

[liemly98]

Steps to reproduce

Link to live example: https://stackblitz.com/edit/github-g7y1kq?file=src%2Fdemo.tsx

Steps:

1. Click on To Date.
2. Select hour.
3. Drag on clock.

Current behavior

The behavior when holding the cursor on to date and from date is different. The Clock changes so fast.

Expected behavior

The behavior when holding the cursor on to date will be the same with from date.

Context

Hi guys, I hope you are doing great.

I'm using a combination of MobileDateTimeRangePicker and renderTimeViewClock. But something seems wrong with the time clock to date.

Here are some images:

Your environment

npx @mui/envinfo

  System:
    OS: macOS 14.0
  Binaries:
    Node: 18.17.1 - ~/.nvm/versions/node/v18.17.1/bin/node
    npm: 9.6.7 - ~/.nvm/versions/node/v18.17.1/bin/npm
    pnpm: 8.7.6 - ~/.nvm/versions/node/v18.17.1/bin/pnpm
  Browsers:
    Chrome: 125.0.6422.61
    Edge: Not Found
    Safari: 17.0
  npmPackages:
    @emotion/react: ^11.11.4 => 11.11.4 
    @emotion/styled: ^11.11.5 => 11.11.5 
    @mui/material: ^5.15.17 => 5.15.17 
    @mui/x-date-pickers: ^7.5.0 => 7.5.0 
    @mui/x-date-pickers-pro: ^7.5.0 => 7.5.0 
    @mui/x-license: ^7.2.0 => 7.2.0 
    @types/react: ^18 => 18.3.1 
    react: ^18 => 18.3.1 
    react-dom: ^18 => 18.3.1 
    typescript: ^5 => 5.4.5 

Search keywords: renderTimeViewClock, MobileDateTimeRangePicker, plan:pro
Order ID: 89947

[LukasTy]

@liemly98 Thank you for reporting this problem.
Such a behavior case has not been fully tested and might be a bit difficult to support—I'm specifically referring to the fact that a 12-hour clock is needed and the TimeClock component is being used for it. 🤔
Just confirming, that the behavior seems almost correct with ampm={false}, though, the view jumping problem remains on the end range position. 😉
I'm adding this issue to the grooming board. 👍

[liemly98]

Thank you so much. With ampm={false}, The issue still is the same.

[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.

@liemly98: How did we do? Your experience with our support team matters to us. If you have a moment, please share your thoughts in this short Support Satisfaction survey.

[liemly98]

@liemly98 Thank you for reporting this problem. Such a behavior case has not been fully tested and might be a bit difficult to support—I'm specifically referring to the fact that a 12-hour clock is needed and the TimeClock component is being used for it. 🤔 Just confirming, that the behavior seems almost correct with ampm={false}, though, the view jumping problem remains on the end range position. 😉 I'm adding this issue to the grooming board. 👍

Hi Lukas, I was wondering how long it takes to fix this bug?

[LukasTy]

Hi Lukas, I was wondering how long it takes to fix this bug?

There are two problems here.

1. The problematic views management when end range position values are being selected
2. The problematic meridiem (am/pm) behavior when selecting it on TimeClock (the user is not taken to the first view of the end range position)

Without trying to debug, I think the 1st is easier to address and I'll try to find some time to look at it this week, while the 2nd problem might require more time.

[LukasTy]

During the grooming, we decided that this issue is for fixing the 1st point in the #13180 (comment).
I've created a separate issue for the 2nd point.
Resolving this issue should allow TimeClock to be used as a time view renderer in DateTimeRangePicker without problems on a 24-hour clock.