Material-ui-pickers: KeyboardDateTimePicker forgets timezone when edited via keyboard

[nareshbhatia]

Environment

| Tech | Version |
| -------------------- | ------- |
| @material-ui/pickers | 3.2.8 |
| material-ui | 4.8.0 |
| TypeScript | 3.7.2 |
| React | 16.12.0 |
| Browser | Chrome |
| Peer library | moment | |

Steps to reproduce

1. Initialize KeyboardDateTimePicker with a moment value which includes a timezone.
2. Change date/time using interactive clock controls. Timezone is preserved.
3. Change date/time using keyboard. Timezone is lost.

Expected behavior

Moment's timezone component should be preserved when changing date/time using keyboard

Actual behavior

Timezone component is lost

Live example

https://codesandbox.io/s/github/nareshbhatia/mui-datetimepicker-demo/tree/master/?fontsize=14&hidenavigation=1&theme=dark

The example displays the time + timezone value supplied to KeyboardDateTimePicker. Also prints on the console whenever it is changed. First change via interactive clock control. See that timezone is preserved. Then change via keyboard. See that timezone is lost.

[nareshbhatia]

Any thoughts? I am blocked on this one. Is this a real bug or I am just using it wrong?

[oliviertassinari]

@nareshbhatia Oh, the Select component is so slow with all the timezones 🙈. Did you consider using the Autocomplete?

---

I think that it would make sense to keep the timezone of the provided date value when modified with the keyboard.

[nareshbhatia]

@oliviertassinari, I too realized that the Select component is too slow with so many timezones. My real app uses react-select, which is pretty fast. I will also try Autocomplete when I get a chance.

In any case, the issue does not even require the Select component. Just typing in the date/time value is enough. Thanks for confirming the bug. I hope this can be resolved soon.

[mihaibogdan]

Hi @oliviertassinari
Not sure if it helps you but this happens on KeyboardDatePicker too.

Thank you for looking into it!

[nareshbhatia]

It would help to know if this bug is on the radar to fix. Or is this something that would be addressed in the next major release? It's kind of important to give power users a quick way to type in a date vs. having to use the interactive controls.

[nareshbhatia]

I see that v4.0.0-alpha.5 is out. Congrats!

Trying to decide if I should switch to it.

• Is this issue being addressed in v4? i.e. will the keyboard input honor timezone.
• Is the timezone support unchanged? i.e. are moment, date-fns, luxon and dayjs still supported?

[valen22br]

Hi @oliviertassinari and @nareshbhatia ,

I'm facing the same problem. Is there a fix or workaround for this bug already?

Thanks!

[oliviertassinari]

Can the bug still be reproduced in @material-ui/[email protected]?

[valen22br]

I'll have to test against v4.

Is there any documentation for migrating from version 3 to 4?
I only found the release notes on https://github.com/mui-org/material-ui-pickers/releases.

[oliviertassinari]

Is there any documentation for migrating from version 3 to 4?

1822

[nareshbhatia]

@valen22br, I haven't tried v4 yet. Would love to hear about your findings.

[valen22br]

I'm getting an error after upgrading to V4:

Uncaught TypeError: Cannot read property 'keyboardDateTime' of undefined at useInterceptProps (DateTimePicker.tsx:92) at PickerWithState (makePickerWithState.tsx:59) at renderWithHooks (react-dom.development.js:14803) at mountIndeterminateComponent (react-dom.development.js:17482) at beginWork (react-dom.development.js:18596) at HTMLUnknownElement.callCallback (react-dom.development.js:188) at Object.invokeGuardedCallbackDev (react-dom.development.js:237) at invokeGuardedCallback (react-dom.development.js:292) at beginWork$1 (react-dom.development.js:23203) at performUnitOfWork (react-dom.development.js:22154)

When I use ampm property, utils.formats.keyboardDateTime is undefined.
When I remove the ampm property, then utils.is12HourCycleInCurrentLocale() is undefined.

Any clues on that?

[dmtrKovalenko]

It looks like you didn't update @date-io/ adapter. It is required to update to the >v2

[valen22br]

Thanks, @dmtrKovalenko, that solved my problem. Now I have V4.

The good news is that this bug can not be reproduced in @material-ui/[email protected].

Are there any plans to fix it on version 3? Version 4 has a lot of new changes, so I imagine that many developers won't migrate right away. If not, when a stable V4 will be released?

Thanks!

[oliviertassinari]

@valen22br Thanks for confirming that the bug was fixed in v4. I think that we should add a test case for it before closing, it will help in future refactoring.

Regarding v3, we don't support it anymore. Regarding v4, it's still unclear when we will be done with it. You could consider it as a rewrite. We might also want to ship it at the same time than Material-UI v5, following a close release schedule, for consistency of the developer experience. I would be leaning for this option until we get most of the problems solved with the components. It's safer (exactly as we do with the lab, I would consider pickers the equivalent of a v0.x version, for now). We will see.

[nareshbhatia]

@valen22br, mind sharing your sample code?

[valen22br]

Hi @nareshbhatia,

To test, I migrated my entire project to the new version. I don't have a small sample code to share.
What I noticed is that I'll have to do a lot of refactoring due to the differences between V3 and V4. The changes are mainly related to the UI.

[oliviertassinari]

Here is a starting point for a reproduction with v4@next https://codesandbox.io/s/material-ui-date-picker-ppt05 :). I'm closing until we have a reproduction.

Please note that we are not quite yet done with breaking changes. The most likely outcome is that we will keep making them, up to a stable release with the v5.0.0 of the library, probably in 6-8 months.

[nareshbhatia]

Thanks for the example, @oliviertassinari. Just curious if the interactions are intentional. Specifically the feedback on the keyboard control is not instantaneous. For example, on the time picker, I have to select the hour and then the minutes for keyboard control to reflect the change. Also, I was not able to change from PM to AM. If this is still work in progress, that's fine - just want to communicate my observations. Thanks again for the sample.

[oliviertassinari]

@nareshbhatia Yeah, this is another issue, it's pretty close to #1651. There are a couple of isolated states to consider here:

• value/defaultValue/onChange, this is the selected date by the user. It can be saved in the database
• displayedValue/onDisplayedValueChange, this is the currently displayed view of the date picker. It can be used to programmatically display a different month or to switch to a different view (year, month, etc).
• selectedValue/onSelectedValueChange, this is the currently selected date(s). Meaning shown as selected in the popup but yet to be confirmed by the user.
• inputValue/onInputValueChange, this is the string value of the textbox.

I'm leaning toward exposing them all. We also need to make sure these different states are correctly synchronized.