[pickers] Always use the same timezone in the field, the view and the layout components #13481
Conversation
… layout components
flaviendelangle
added
bug 🐛
| @@ -165,19 +165,31 @@ export const usePickerValue = < | |||
| const { | |||
| onAccept, | |||
| onChange, | |||
| value: inValue, | |||
| value: inValueWithoutRenderTimezone, | |||
There was a problem hiding this comment.
I'm using a super explicit variable name here to lower the risk of re-using the variable below instead of the one with the right timezone.
There was a problem hiding this comment.
Do you think that having inValue and inValueWithTimezone would not be enough? 🤔
Or even as we have everywhere else: inValue and value for the value returned from useValueWithTimezone..? 🤔
There was a problem hiding this comment.
The issue with naming the value returned by useValueWithTimezone is that we have the values that are stored in the state (the other usages of useValueWithTimezone don't have this issue), so the value returned by useValueWithTimezone is still not the value the we should use for most of the usages.
So I'd prefer to keep some information on the variable returned by useValueWithTimezone saying that it's still an "input" value.
There was a problem hiding this comment.
We have so many values in this hook 😆
props.valueprops.defaultValue- the value returned by
useValueWithTimezone dateState.draftdateState.lastPublishedValuedateState.lastComittedValuedateState.lastControlledValue
There was a problem hiding this comment.
Ok, if you feel that it improves the clarity, let's go with that approach. 👌
There was a problem hiding this comment.
Alternatively I can rename inValueWithRenderTimezone into inValue since it's the one we use as "props.value" in 90% of the file
|
Deploy preview: https://deploy-preview-13481--material-ui-x.netlify.app/ |
| @@ -165,19 +165,31 @@ export const usePickerValue = < | |||
| const { | |||
| onAccept, | |||
| onChange, | |||
| value: inValue, | |||
| value: inValueWithoutRenderTimezone, | |||
There was a problem hiding this comment.
Do you think that having inValue and inValueWithTimezone would not be enough? 🤔
Or even as we have everywhere else: inValue and value for the value returned from useValueWithTimezone..? 🤔
I added one very basic test that reproduces the issue 👍 |
… layout components (mui#13481)
… layout components (mui#13481)
Fixes #13319
Looks like the fix is easier than expected
All the tests are passing, for me this is fixing the root issue since
usePickerValuereturns the value that will be used in all the pieces of the picker.I first tried to pass the
timezoneto theToolbar, but it's quite fragile since we could have the exact same problem in other parts of the UI (the shortcuts for instance).