[pickers] Add Temporal to date-librairies

[MarinePicaut]

It would be great to add the Temporal API as a part of date-librairies to the Date / Time pickers component

• [x] I have searched the issues of this repository and believe that this is not a duplicate.

Summary 💡

It should work same as the others date-librairies supported by the component.

Examples 🌈

Same as here

Motivation 🔦

[Temporal](https://github.com/tc39/proposal-temporal is the future, currently stage 3

[eps1lon]

You can use any date library you want as long as it implements the required interface of LocalizationProvider#dateAdapter.

So you can already use the Temporal API. This is for now the better approach since we don't want to maintain an implementation relying on experimental APIs. Once it becomes stable we can include the implementation in the lab.

[remy90]

This proposal is now in the hands of ECMAScript engine implementers, so the bar for making API changes is extremely high - https://github.com/tc39/proposal-temporal/tree/main/#polyfill

I'm also interested in using the Temporal API polyfill. Has anyone tried implementing the dateAdapter interface?

[mbrevda]

Looks like temporal is beginning to ship in Firefox https://developer.mozilla.org/en-US/blog/javascript-temporal-is-coming/ https://bugzilla.mozilla.org/show_bug.cgi?id=1946823

edit: fwiw this is shipped or shipping in Chrome, node, deno, and bun, too: https://chromestatus.com/feature/5668291307634688 https://github.com/nodejs/node/pull/57128 https://github.com/oven-sh/bun/issues/15853 https://github.com/denoland/deno/pull/21738, https://deno.com/blog/v1.40#temporal-api

[httpete-broadcom]

+1 for this. Temporal will eliminate the need for the others and standardize dates and times in Js once and for all natively.

[DASPRiD]

I think that mui/x-date-pickers first needs an internal overhaul for this to be implemented properly.

1. The adapter interface needs to understand the different concepts of local date, local time, local date time and zoned date time.
2. There is no concept of token parsing/formatting in Intl.DateTimeFormat, which makes this relatively hard to implement

I'm currently working on a prototype myself which to implement the different concepts for the current adapter interface. The plan is to have a different adapter wrapper you have to put around your actual <DatePicker />, e.g.:

<TemporalPlainDate>
    <DatePicker />
</TemporalPlainDate>

On top of that, there is a <TemporalLocaleProvider /> which can globally inject the locale for all wrappers.

Each individual adapter applies checks to make sure that it's not used in the wrong context (e.g. TemporalPlainDate mixed with a TimePicker). I'm also going to have to limit the format tokens which can be used for keyboard input, as I have to parse these out of Intl.DateTimeFormat, which is not very reliable once you are looking at non-numeric tokens… there are a lot of caveats.

I hope I'll be able to release something soon'ish.

[DASPRiD]

AAAAAAND done! I appreciate any testing and reports! :)

https://www.npmjs.com/package/mui-temporal-pickers

[mbrevda]

Oh, cool! Is this something that would make sense to contribute back to MUI?

[DASPRiD]

I don't think in he current form, no. I'm really hacking around the localization's adapter capabilities right now. The adapter architecture either needs a complete overhaul or (potentially in the future?) adapters could just be dropped completely and Temporal could become the only thing needed.

[mbrevda]

Temporal is shipping in Chrome 144, set for release Jan. 17, 2026

[DASPRiD]

I've also added support for PlainYearMonth and PlainMonthDay to mui-temporal-pickers now :)