Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[pickers] Fix DateCalendar timezone management #12321

Open
wants to merge 4 commits into
base: master
Choose a base branch
from

Conversation

LukasTy
Copy link
Member

@LukasTy LukasTy commented Mar 4, 2024

Fixes #10804

Closes #12256

The referenceDate and calendarState.currentMonth were not updating when the timezone prop changes.

Changed to:

  • update the internal referenceDate value when the provided referenceDate or timezone prop change
  • update internal calendarState.currentMonth value when referenceDate changes

@LukasTy LukasTy added bug 🐛 Something doesn't work component: pickers This is the name of the generic UI component, not the React module! needs cherry-pick The PR should be cherry-picked to master after merge time-zone Issues about time zone management labels Mar 4, 2024
@LukasTy LukasTy self-assigned this Mar 4, 2024
@LukasTy LukasTy changed the title Fix date calendar timezone [pickers] Fix DateCalendar timezone management Mar 4, 2024
@mui-bot
Copy link

mui-bot commented Mar 4, 2024

Deploy preview: https://deploy-preview-12321--material-ui-x.netlify.app/

Generated by 🚫 dangerJS against f36ed3a

Copy link
Contributor

@shaharyar-shamshi shaharyar-shamshi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added some tentative review. will check further by running it.

screen.getAllByRole('gridcell', {
name: (_, element) => element.nodeName === 'BUTTON',
}).length,
).to.equal(30);
Copy link
Contributor

@shaharyar-shamshi shaharyar-shamshi Mar 4, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the correct assertion should be number of grid cell of type button before and after the timezone change should be same. (I assume for month of february and month having 31 days it might fail)

and more accurate way of doing this will be before the the timezone change create the map of index of date in gridcell and compare it after the timezone change

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for noting. 🙏
I've seen your tests and do agree that they are more "complete", but IMHO, I don't see the benefit of having a more complex-to-read test with marginally stricter assertions. The main thing that we need to assert here is that the same amount of days have been rendered after a timezone switch. 🤔
I do value the benefit of simple tests, which you can glance over and understand in seconds. 🙈
What do you think?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I totally agree simple is better. But there might be chance in month of july and August also december 2024 and January 2025 when consecutive months have equal number of dates then this might not cover those edge cases.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But there might be chance in month of july and August also december 2024 and January 2025 when consecutive months have equal number of dates then this might not cover those edge cases.

Why do you think like that? 🤔
The test is set to use 1 calendar for simplicity and ("current") time is mocked to 2022-06-15.

Maybe you are talking about a separate issue (#10584) with AdapterDayjs and DST?
That's a separate topic that I'm looking into. 😉

Copy link
Contributor

@shaharyar-shamshi shaharyar-shamshi Mar 5, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No I am not talking about DST. although I missed the date mocking part. I assume it would render the calendar of current.

With date mocking your test will work.

Sorry for missing date mocking part.

#12321 (comment)

I think this is bug

@@ -9,7 +9,9 @@ import { createPickerRenderer, adapterToUse } from 'test/utils/pickers';
const isJSDOM = /jsdom/.test(window.navigator.userAgent);

describe('<DateCalendar />', () => {
const { render, clock } = createPickerRenderer({ clock: 'fake' });
const { render, clock } = createPickerRenderer({
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

seems to be unintentional change

}
render(<DateCalendarWithControlledTimezone />);

expect(
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

same as above you can check my PR I have done in same way

@shaharyar-shamshi
Copy link
Contributor

shaharyar-shamshi commented Mar 4, 2024

I think there is some bug in BasicDateRange selecting any range (let's assume 12 March to April 21) having America/New_York as the timezone now change the timezone to UTC

there is no change in the range of the calendar. also when switching while you will notice some flicker.

Same is happening with the DateCalendar

@LukasTy

Copy link

This pull request has conflicts, please resolve those before we can evaluate the pull request.

@github-actions github-actions bot added the PR: out-of-date The pull request has merge conflicts and can't be merged label Mar 11, 2024
@LukasTy LukasTy changed the base branch from next to master March 25, 2024 14:55
@github-actions github-actions bot removed the PR: out-of-date The pull request has merge conflicts and can't be merged label Mar 26, 2024
@jesse-garrison-panther
Copy link

Hello all, just checking in on this and trying to understand where things are at timeline wise. It looks like this PR fixes an issue I ran into a while ago, so I'm looking forward to this being merged. Is this PR unable to be merged because there is a dependency on a fix for this other bug?

Thanks for any info you can provide!

@LukasTy
Copy link
Member Author

LukasTy commented Mar 29, 2024

Hello all, just checking in on this and trying to understand where things are at timeline wise. It looks like this PR fixes an issue I ran into a while ago, so I'm looking forward to this being merged. Is this PR unable to be merged because there is a dependency on a fix for this other bug?

Thanks for any info you can provide!

Hey @jesse-garrison-panther, this PR fixes your mentioned problems.
It got delayed because I was looking at fixing a different problem, but it would probably make sense to limit the scope of this PR to only fixing the particular problem with the Calendar months calculation and leave the AdapterDayjs issues with DST separate. 🤔

@jesse-garrison-panther
Copy link

Hey @jesse-garrison-panther, this PR fixes your mentioned problems. It got delayed because I was looking at fixing a different problem, but it would probably make sense to limit the scope of this PR to only fixing the particular problem with the Calendar months calculation and leave the AdapterDayjs issues with DST separate. 🤔

@LukasTy Thanks for the clarification! It would be great if this fix could go out separately from the DST issue you mentioned, although I don't have enough context around that other issue and how it might affect this fix. If they can both be fixed in a similar timeline, that's fine too. I just know personally I've been looking forward to using a new DatePicker component our team built, but the bug I originally filed is preventing us from using it until it's fixed.

Thanks for all the great work you and the team is providing with MUI though!

@LukasTy LukasTy force-pushed the fix-date-calendar-timezone branch from 9007ca4 to f36ed3a Compare April 4, 2024 12:05
React.useEffect(() => {
dispatch({
type: 'changeMonth',
newMonth: utils.startOfMonth(referenceDate),
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are we sure this change is wanted?
From what I can understand it will reset the displayed month to referenceDate, so if the user had moved to another month and then the timezone changes it might be weird.

Tbh this is really an edge case and I could understand that we don't want to optimize for it


More problematic, this will break if the component re-renders and referenceDate is passed directly is not memoized (which we support for now and we should keep supporting IMHO):

import * as React from 'react';
import dayjs from 'dayjs'
import Stack from "@mui/material/Stack";
import Switch from "@mui/material/Switch";
import { DemoContainer } from '@mui/x-date-pickers/internals/demo';
import { AdapterDayjs } from '@mui/x-date-pickers/AdapterDayjs';
import { LocalizationProvider } from '@mui/x-date-pickers/LocalizationProvider';
import { DateCalendar } from '@mui/x-date-pickers/DateCalendar';

export default function BasicDateCalendar() {
    const [isActive, setIsActive] = React.useState(false)

    return (
        <Stack spacing={2}>
            <Switch value={isActive} onChange={event => setIsActive(event.target.checked)} />
            <LocalizationProvider dateAdapter={AdapterDayjs}>
                <DemoContainer components={['DateCalendar']}>
                    <DateCalendar referenceDate={dayjs('2022-04-17')} />
                </DemoContainer>
            </LocalizationProvider>
        </Stack>
    );
}

Copy link

This pull request has conflicts, please resolve those before we can evaluate the pull request.

@github-actions github-actions bot added the PR: out-of-date The pull request has merge conflicts and can't be merged label May 29, 2024
@michelengelen michelengelen removed their request for review June 10, 2024 09:34
@jesse-garrison-panther
Copy link

Hello all, I'm just following up on this issue to see if there is a timeline of when it's expected to be merged? We've built a new date picker component that we're waiting to use, but this bug is currently a blocker. FWIW, we're also part of the Pro Plan. Thanks for any updates you can provide! 🙏

@LukasTy
Copy link
Member Author

LukasTy commented Jul 18, 2024

Hello all, I'm just following up on this issue to see if there is a timeline of when it's expected to be merged?

@jesse-garrison-panther Thank you for bringing this topic up.
We plan to finish this PR within around a month.
Is that a reasonable timeframe?

@jesse-garrison-panther
Copy link

We plan to finish this PR within around a month. Is that a reasonable timeframe?

@LukasTy Thanks for the reply. Yes, I think that timeframe will work.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug 🐛 Something doesn't work component: pickers This is the name of the generic UI component, not the React module! needs cherry-pick The PR should be cherry-picked to master after merge PR: out-of-date The pull request has merge conflicts and can't be merged time-zone Issues about time zone management
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[pickers] DateCalendar timezone prop doesn't seem to work (see demo)
5 participants