[pickers] The components should be able to work with UTC dates

[scallaway]

Duplicates

• [X] I have searched the existing issues

Latest version

• [X] I have tested the latest version

Summary 💡

It would be really nice if there was a prop that you could pass to the Date Picker in order to specify that for each date that is selected, this should be the UTC form of the date.

Currently, you're only able to specify a locale for the Date Picker (through the Localization component) and this is very limiting, especially when timezones aren't required in certain applications.

Examples 🌈

        <DesktopDatePicker
          label={dateTitle}
          onChange={handleChange}
          value={value}
          views={DATE_PICKER_VIEWS}
          minDate={minimumDate || undefined}
          maxDate={maximumDate || undefined}
          InputProps={inputProps}
          showToolbar={true}
          renderInput={renderInput}
          useUTC
        />

Just a simple boolean prop could be passed to the component.

Motivation 🔦

In our use case, we have UTC timestamps used throughout our application. This meant that when we added the latest version of the Date Picker (after upgrading to MUI v5), there were numerous problems.

We're now having to do some custom manipulation of dates in order to get the values that we want, rather than being able to trust the values that come out of the Date Picker (which is what we were doing happily with v4).

It seems like there were a number of regressions both in terms of UX and developer experience between v4 and v5 for the Date Pickers which is a real shame, and we would love to see some more work done on these since they're pretty vital in our application!

Order ID 💳 (optional)

No response

[alexfauquette]

I'm not sure to understand what this prop should do.

Except for the "today" button that depends on the timezone, I do not see how timezone affects the behavior of the component. If you want to only manipulate UTC values, you can use adapter.date().utc(true) for the value and onChange props

https://codesandbox.io/s/basicdatetimepicker-demo-mui-x-forked-95qp56?file=/demo.tsx

For now, I'm not sure it's feasible since date-io does not support timezone management across the 4 main libraries

---

In our use case, we have UTC timestamps used throughout our application. This meant that when we added the latest version of the Date Picker (after upgrading to MUI v5), there were numerous problems.

We're now having to do some custom manipulation of dates in order to get the values that we want, rather than being able to trust the values that come out of the Date Picker (which is what we were doing happily with v4).

Could you detail what you do and what is going wrong?

[scallaway]

https://codesandbox.io/s/basicdatetimepicker-demo-mui-x-forked-gyzmsn?file=/demo.tsx

This is pretty much exactly the problem that we're seeing, it's a different example to what you provided.

Could you detail what you do and what is going wrong?

I think the key point is that we're not supplying a date to the Date Picker to begin with, so it's starting off as null.

If the user selects a date, then they're selecting that date at midnight in their own locale. In the example, this can be seen from the rawValue output.

The result of this is that the UTC version of the date becomes offset, I'm in the UK and since we're currently still in Summer Time, the UTC version of the date ends up being the day before the date that I select.

All this being said, I'm not sure whether this ends up being a Date Picker problem or more of a Moment problem (which is what we use throughout our application for dates).

I'm hoping that clears it up!

[alexfauquette]

Thanks for clarification. That looks more like a moment issue.

In the codesandbox I provided, it works event if you start with null. The reason being .utc(true) convert to UTC format but keep the same date.

method	input (UTC+2)	output (UTC)
`.utc(true)`	12:00	12:00
`.utc()`	12:00	10:00

Here si a demo

https://codesandbox.io/s/basicdatetimepicker-demo-mui-x-forked-95qp56?file=/demo.tsx

[alexfauquette]

It seems like there were a number of regressions both in terms of UX and developer experience between v4 and v5 for the Date Pickers which is a real shame, and we would love to see some more work done on these since they're pretty vital in our application!

Do you have more details such that could have a look to them?

[koooge]

:+1:

Understood this is a limitation of date-io, but it's necessary to show UTC on DatePicker with date-fns in my use case. Since DatePicker regards input value as local timezone, the value has to be pre-converted UTC to "inverted" local time I think. Otherwise, DatePicker displays unexpected time unless using GMT. I made the sample code. https://codesandbox.io/s/basicdatetimepicker-demo-mui-x-forked-7h5o8n?file=/demo.tsx The component receives ISOString and manipulates datetime in UTC throughout. This is a common use case I would say.

[dcorb]

I fixed this by defining a global timezone, because in our app, we prefer to ignore user's local timezone. The user understands that the date they are picking is according to Norwegian time. ymmv

import moment, { Moment } from "moment-timezone";
moment?.tz?.setDefault("Europe/Oslo");

Docs https://momentjs.com/timezone/docs/#/using-timezones/default-timezone/

[flaviendelangle]

Closing this issue in favor of https://github.com/mui/mui-x/issues/8484