[pickers] `DateTimeRangePicker` throws error with `format` prop in MUI X Pro v7.11.0

[kater1naa]

Steps to Reproduce

1. Install @mui/x-date-pickers-pro version 7.11.0.
2. Use the DateTimeRangePicker component with a format prop, as shown below:

import React, { useState } from 'react';
import { LocalizationProvider } from '@mui/x-date-pickers-pro';
import { AdapterDayjs } from '@mui/x-date-pickers-pro/AdapterDayjs';
import { DateTimeRangePicker } from '@mui/x-date-pickers-pro/DateTimeRangePicker';
import dayjs, { Dayjs } from 'dayjs';

export default function BuggedDateTimeRangePicker() {
  const [value, setValue] = useState<[Dayjs | null, Dayjs | null]>([dayjs(), dayjs().add(1, 'day')]);

  return (
    <LocalizationProvider dateAdapter={AdapterDayjs}>
      <DateTimeRangePicker
        value={value}
        onChange={(newValue) => setValue(newValue)}
        disablePast
        format="DD/MM/YYYY" // This prop causes the error
      />
    </LocalizationProvider>
  );
}

Current behavior

Problem: The format prop causes the DateTimeRangePicker component to throw two unclear errors when the user clicks on the calendar.

Expected behavior

The format prop should work as described in the documentation and allow customization of the date format without causing runtime errors.

Context

Context:

I'm working on a project using MUI X Pro components, specifically the DateTimeRangePicker, integrated with a React and Material-UI-based form. The form uses react-hook-form for validation, and Day.js for date handling.

Summary of the Problem:

Problem: The format prop on the DateTimeRangePicker causes an error when the user clicks on the calendar. Current Impact: Unable to customize the date format as needed. Expected Behavior: The format prop should work as described in the documentation and allow customization of the date format without runtime errors.

Solution Sought:

I'd like to request the MUI X team to investigate whether this is a bug in how the format prop is handled or if there's missing configuration that needs to be documented.

Implementation Details:

Frontend Framework: React (v18.0.0) Date Library: Day.js MUI Components: @mui/material v5.15.19, @mui/x-date-pickers-pro v7.11.0 Form Management: React Hook Form Picker Setup: DateTimeRangePicker wrapped inside LocalizationProvider using the AdapterDayjs.

Here’s the snippet causing the issue:

<DateTimeRangePicker
  value={dateRange}
  onChange={handleDateRangeChange}
  disablePast
  format="DD/MM/YYYY" // This prop causes the error
/>

Current Workaround: Removing the format prop resolves the error, but I need to customize the date format as per design requirements.

Your environment

Environment

• @mui/x-date-pickers-pro version: 7.11.0
• @mui/material version: 5.15.19
• React version: 18.0.0
• Browser: Chrome v116.0.5845.97 (64-bit)
• Operating System: macOS

Search keywords: DateTimeRangePicker

[michelengelen]

Hey @kater1naa and thanks for opening this issue. It is indeed a bug and there is a pretty simple solution to it.

diff --git a/packages/x-date-pickers/src/internals/hooks/useField/useField.utils.ts b/packages/x-date-pickers/src/internals/hooks/useField/useField.utils.ts
index 71b5465dc..26bb33201 100644
--- a/packages/x-date-pickers/src/internals/hooks/useField/useField.utils.ts
+++ b/packages/x-date-pickers/src/internals/hooks/useField/useField.utils.ts
@@ -817,7 +817,8 @@ export const parseSelectedSections = (
   }

   if (typeof selectedSections === 'string') {
-    return sections.findIndex((section) => section.type === selectedSections);
+    const index = sections.findIndex((section) => section.type === selectedSections);
+    return index === -1 ? null : index;
   }

I will add this to the board but label it as a good first issue for the community to pick up, so if you want you can also pick this up. 👍🏼

[flaviendelangle]

I'd be interested to have a reproduction case here before applying a fix. I agree that the failsafe proposed by @michelengelen make sense, but I would like to understand why we have an invalid selected section in the first place

[github-actions[bot]]

The issue has been inactive for 7 days and has been automatically closed.

[LukasTy]

@flaviendelangle this is happening, because we try to parse hours section after the selection of a day in the calendar. In essence, this is an improper format for the DateTimeRangePicker, because it lacks the time format part. Applying the suggested fix ruins the UX of the data selection, hence, I'm not sure if this is the best solution. 🤔 I'm not against applying the fix, because it makes sense, but I feel like it won't solve this problem case correctly. 🙈

WDYT? Can we ignore this UX shortcoming in such edge-cases given that we plan to move away from the tooltip behavior for range pickers? 🤔

---

@kater1naa Could you elaborate on your use case? Do you specifically need to have only date format, but have the option to change the time value only in view? 🤔 Maybe using the DateRangePicker would be a better fit if time data is not needed? 🤔

[github-actions[bot]]

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] @kater1naa 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.

[flaviendelangle]

Applying the suggested fix ruins the UX of the data selection, hence, I'm not sure if this is the best solution. 🤔

Is this the fixed you just merged ? :laughing:

[LukasTy]

Is this the fixed you just merged ? 😆

Yes, I think that the fix makes sense to avoid complete edge-case failures, but we can discuss if we want any more elaborate solutions to handle such cases more properly before we change the interaction approach. 🤔

[flaviendelangle]

No problem keeping it simple for now :+1: