[pickers] DateCalendar week day label are not understandable with the hebrew locale

[3pleFly]

Steps to reproduce

Link to live example: https://codesandbox.io/s/date-picker-material-ui-forked-5q52m6?file=/src/App.js

1. Use "@mui/x-date-pickers": "^6.16.3"
2. Use , all from the correct imports.
3. Doesn't work properly.

Current behavior

Expected behavior

it should be -

Not sure why it is like that. I could not for the life of me find a way to 'customize' the days of week either, so I ended going back version until worked ( "@mui/x-date-pickers": "^5.0.0-beta.1" )

Context

No response

Your environment

chrome.

Search keywords: Date Picker

[flaviendelangle]

Hi,

Thanks for your contribution
Right now, our default day label is the 1st letter of the day.
But it seems that for the hebrew locale this gives a very bad result.
I doubt that we can find a better default, but you can override the default behavior: https://codesandbox.io/s/date-picker-material-ui-forked-jj4fn2?file=/src/App.js

Maybe for your locale if make sense to just have the 7 labels hardcoded: https://codesandbox.io/s/date-picker-material-ui-forked-gr58rp?file=/src/App.js

You can find the doc here

Just so that you know, if the next major we will remove the day parameter and only keep the date one, that's why I'm using this one 👍

[LukasTy]

A small clarification: to achieve the same behavior you'd need to make a minor adjustment to the suggested code:

- const formattedDay = format(date, "EEE", { locale: he });
+ const formattedDay = format(date, "EEEEE", { locale: he });

- return formattedDay;
+ return formattedDay.charAt(0); 

In regards to the problem itself, I think that it is worth flagging it as a regression that should be addressed IMHO. 🤔
The reason is the change in the used formatting.
For example, previously for AdapterDateFns the EEEEEE format has been used:

mui-x/packages/x-date-pickers/src/AdapterDateFns/AdapterDateFns.ts

Line 550 in 5763eca

}).map((day) => this.formatByString(day, 'EEEEEE'));

And now we changed to weekdayShort, which is probably always different from the manually used format previously.

mui-x/packages/x-date-pickers/src/DateCalendar/DayCalendar.tsx

Line 372 in 5763eca

((_day: string, date: TDate) => utils.format(date, 'weekdayShort').charAt(0).toUpperCase());

Maybe for most common locales, this is not a problem, but it's clearly a breaking change in some cases. 🤔
The same issue is also apparent for AdapterLuxon as seen here.

WDYT about keeping the previous behavior for generating the array of weekdays (it was especially elegant and correct in case of luxon) and generating the day to pass to the date parameter differently?
P.S. We already do it here:

mui-x/packages/x-date-pickers/src/DateCalendar/DayCalendar.tsx

Line 576 in 5763eca

aria-label={utils.format(utils.addDays(startOfCurrentWeek, i), 'weekday')}

cc @michelengelen @flaviendelangle

[flaviendelangle]

I'm not sure to understand your entire reasoning @LukasTy , sorry if I misunderstood some of it.

For me we have two slightly related topics here:

1. We changed the format used by AdapterDateFns to generate the label of the day (from EEEEEE to EEE).

That's because before it was hardcoded inside adapter.getWeekdays and we took the closest format available in the adapter formats, which indeed was not exactly the same and it causes the issue described here.

Is there something preventing us from changing the weekdayShort format to equal EEEEEE on date-fns?
I would need to be checked, but I can't find any other usage than the one described in this issue.

For me this point is not related to the fact of using adapter.getWeekdays or not.

3. Luxon does not allow to change the 1st day of the week in the locale and when we used adapter.getWeekdays, people could override the adapter method to change the Luxon start of week day.

I'm not a fan of asking users to override our adapters methods to get the behavior they want.
I agree that the Luxon regression is problematic, but I don't think the previous approach was the right one.
One of the reason is that, for the current example, it only changes the start of the week when using adapter.getWeekdays, so field editing of week day is not impacted for instance.

Concerning the aria-label, it's not using the returned value of the deprecated adapter.getWeekdays method.
Am I missing something, or before the regression, when people overrode the Luxon adapter.getWeekdays method, they would end up with an incoherent aria label (aria-label="Monday" and T displayed in the column for example).

[LukasTy]

Is there something preventing us from changing the weekdayShort format to equal EEEEEE on date-fns?
I would need to be checked, but I can't find any other usage than the one described in this issue.

Yes, that is indeed doable, just with a bit of inconsistency...
Both dayjs and moment do not have a token to format the date into a single-letter weekday format. 😢 And luxon doesn't have a format that produces a 2 letter weekday representation. 🤷 🙈
We'd end up with an inconsistency that could bite us in the long run.
However, maybe almost no one is using this format and or overriding it, thus, we could handle this inconsistency internally with little to no side effects. 🤔
WDYT, would you say that we should aim to avoid this bug by introducing the slight inconsistency?

For me this point is not related to the fact of using adapter.getWeekdays or not.

IMHO, it's slightly related, because the mentioned method avoided the inconsistency by avoiding the usage of singular defined format. 🤷

---

3. Luxon does not allow to change the 1st day of the week in the locale and when we used adapter.getWeekdays, people could override the adapter method to change the Luxon start of week day.

Do I understand it correctly that after the recent change, we no longer support changing the start of the weekday on Luxon adapter by overriding the getWeekdays method? 🤔
It would suggest that there are a couple of possible breaking changes in this case. 🙈
However, I would agree with you on this part—changing the start of the week using the mentioned method seems hacky at best and realistically is probably a recipe for disaster. 😆

---

I mentioned the aria-label case for the fact that we are already building date objects to display a label, hence, my suggestion of keeping the usage of the now deprecated adapter.getWeekdays to generate the weekday labels would not have a performance impact. 😉 TL.DR.: This last point is an optional note that can be ignored. 🙈

[flaviendelangle]

IMHO, it's slightly related, because the mentioned method avoided the inconsistency by avoiding the usage of singular defined format. 🤷

But if we just change the weekdayShort format of AdapterDateFns, we end up with the exact same behavior as before (except for the Luxon start of the week topic) everywhere inside our pickers no?
Since the only place we use weekdayShort is here.

Do I understand it correctly that after the recent change, we no longer support changing the start of the weekday on Luxon adapter by overriding the getWeekdays method?

Yes, it's an unexpected regression that we must adress somehow I guess.
I would like us to discuss if we have a better solution than this override.
Two APIs that I can think about:

• a prop on LocalizationProvider to set the start of the date that would only be used by Luxon, just like moment uses the dateLibInstance prop
• a new static method on AdapterLuxon (AdapterLuxon.setCustomWeekStart) that returns a Luxon adapter with the correct start of week

[LukasTy]

But if we just change the weekdayShort format of AdapterDateFns, we end up with the exact same behavior as before (except for the Luxon start of the week topic) everywhere inside our pickers no?
Since the only place we use weekdayShort is here.

I will create a PR to handle this. 👌

I would like us to discuss if we have a better solution than this override.

I've created an issue for that: #10805. 😉