[pickers][DatePicker] Weekdays are shifted when using GMT timezone (such as Europe/London)

[jimmyh-onepilot]

Steps to reproduce

• Set up a DatePicker with @mui/x-date-pickers.
• Configure a dayjs timezone to 'Europe/London'.
• Open the calendar and observe the incorrect alignment.

Current behavior

The calendar displays incorrect dates when using the @mui/x-date-pickers with dayjs and setting the timezone to 'Europe/London' (or any GMT timezone).

For example, January 1, 2025, is shown as a Thursday instead of a Wednesday.

I need to display the hours according to the timezone from my event. However, when selecting a date with Europe/London, the current month is wrong (the previous month?) and the days are incorrect.

While it seems to be working as expected for any other timezone, such as Europe/Paris (GMT+1) or Europe/Riga (GMT+2).

Here's my following code:

        <DateTimePicker value={dayjs(start).tz(timezone, true)}.../>

Also tried with this one, but does not seem to resolve the issue.

        <DateTimePicker value={dayjs(start)} timezone={timezone}.../>

Expected behavior

DateTimePicker should also work with values from the GMT timezone and must suggest current month of selected date, and not the previous one.

Also reproduced on the documentation example with 'Europe/London' value.

Context

I need to display the hours according to the timezone from my event, which is currently working. But when coming to selecting a value, it seems to have an issue with events having specific timezone. (such as Europe/London)

Your environment

npx @mui/envinfo

  System:
    OS: macOS 15.1.1
  Binaries:
    Node: 18.18.2 - ~/.nvm/versions/node/v18.18.2/bin/node
    npm: 9.8.1 - ~/.nvm/versions/node/v18.18.2/bin/npm
    pnpm: Not Found
  Browsers:
    Chrome: 131.0.6778.205
    Edge: Not Found
    Safari: 18.1.1
  npmPackages:
    @emotion/react: ^11.9.0 => 11.11.1 
    @emotion/styled: ^11.8.1 => 11.11.0 
    @mui/base:  5.0.0-beta.7 
    @mui/core-downloads-tracker:  5.16.8 
    @mui/icons-material: ^5.16.8 => 5.16.8 
    @mui/lab: ^5.0.0-alpha.121 => 5.0.0-alpha.136 
    @mui/material: ^5.16.8 => 5.16.8 
    @mui/private-theming:  5.16.8 
    @mui/styled-engine:  6.3.1 
    @mui/styles: ^5.16.8 => 5.16.8 
    @mui/system: ^6.3.1 => 6.3.1 
    @mui/types:  7.2.19 
    @mui/utils:  5.13.7 
    @mui/x-date-pickers: ^7.23.3 => 7.23.3 
    @mui/x-internals:  7.23.0 
    @types/react: ^18.3.3 => 18.3.10 
    react: ^18.3.1 => 18.3.1 
    react-dom: ^18.3.1 => 18.3.1 
    typescript: ^4.3.3 => 4.9.5 

Environment:

• @mui/x-date-pickers: 6.14 (Also tried with latest update 7.23.3)
• dayjs: 1.11.5 (Also tried with latest update 1.11.13)
• Build tool: Vite
• OS: macOS Ventura

Search keywords: Picker wrong weekdays timezone

[jimmyh-onepilot]

Looks also related to the following issues already reported:

• [DatePicker] Week day names header doesn't match numbers arrangement when dayjs + timezone + locale #9883
• [pickers] DateCalendar timezone prop doesn't seem to work (see demo) #10804
• The startOf method is not using the current locale when the timezone plugin is enabled iamkun/dayjs#2394

Let me know if you need additional information @flaviendelangle

[michelengelen]

Hey @jimmyh-onepilot ... as you stated correctly this is due to a bug from dayjs when using a zero offset timezone, such as UTC or Europe/London.

duplicate of #9653

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

Note

@jimmyh-onepilot 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.

[jimmyh-onepilot]

Thanks for your reply @michelengelen

This is unfortunate.. is there any workaround or anything to prevent this issue?

[michelengelen]

Thanks for your reply @michelengelen

This is unfortunate.. is there any workaround or anything to prevent this issue?

Well, the obvious workaround is to use a different library like datefns, but I do understand that this might not be possible, especially inside an application where everything is built around dayjs.

Unfortunately we do not have any other workaround as of now and the dayjs maintainer seems relatively inactive (last release was Aug 20, 2024), so fixing this might take a while.