[pickers] Allow to have infinite valid dates (no minDate, no maxDate)

[petermikitsh]

Duplicates

• [X] I have searched the existing issues

Latest version

• [X] I have tested the latest version

Steps to reproduce 🕹

Link to live example: https://mui.com/x/react-date-pickers/date-picker/ (first demo, Basic Usage)

Steps:

1. Type 12/31/2099. Open the popover. Observe that the right arrow (to navigate to January 2100) is disabled.
2. Type 01/01/2100. Open the popover. Observe the input is an error state. The modal opens on January 2100, but dates 12/31/2099 and prior are selectable.

Current behavior 😯

Expected behavior 🤔

Any date should be selectable if minDate and maxDate are not passed as props. And there should be no error treatment (red border on Text input).

Likewise, 01/01/1900 is the earliest selectable date, and 12/31/1899 is disabled.

Context 🔦

No response

Your environment 🌎

npx @mui/envinfo

``` Don't forget to mention which browser you used. Output from `npx @mui/envinfo` goes here. ```

Order ID 💳 (optional)

No response

[alexfauquette]

It can be surprising, but the reason why dates are limited between 1900 and 2099 is the year picker does not support virtualization.

If you have no minDate/maxDate the number of years to display would be infinite. Which we can not support without virtualization

The default min/max dates are the following:

minDate: utils.date('1900-01-01T00:00:00.000')!,
maxDate: utils.date('2099-12-31T00:00:00.000')!,

For which kind of application do you need to go after 2099?

[petermikitsh]

For which kind of application do you need to go after 2099?

I have business logic where a form contains a required date field that represents the record's expiration date. Users will at times intentionally choose a very far-out date to effectively communicate that the record doesn't expire. The user might input the year 2999, for example.

(You could say that having the form structured in this way doesn't make sense, and I'd agree, but the UI form posts to a long-established Rest API which cannot be changed, so I have to continue supporting far out dates via the UI).

[LukasTy]

(You could say that having the form structured in this way doesn't make sense, and I'd agree, but the UI form posts to a long-established Rest API which cannot be changed, so I have to continue supporting far out dates via the UI).

Hey @petermikitsh Have you considered providing a different behaviour for "no expiration" case? IMHO, it seems like a waste of time for users to enter date without any point. 🤷 My position on this case is the following: why do I need to put effort inputting a date when I essentially don't want a date?

You could look into trying something like this:

• Mention somewhere near the input field that if it is empty - the record will have no expiration
• Add a checkbox "No expiration" and disable expiration date field once its toggled

In both of these cases—send an arbitrarily distant date (i.e. new Date(2999, 11, 31, 23, 59, 59)) as an expiration date to the endpoint.

[ewerkema]

@alexfauquette We would also like to have the option to extend the maximum date. Our use case is that we have e2e tests running in parallel on the frontend. The communication is done with a single backend and therefore needs to separate data per page. The best way to do this for our applications is to run each test on a unique day, but we are now limited to 2099 (only 18000 possibilities). Is it difficult to add virtualization (or have an option for us to override this)?

[alexfauquette]

Is it difficult to add virtualization (or have an option for us to override this)

It's not that trivial. It might be easier to use something else than a date to identify your test compared to opening a PR fixing this issue.

[pkernevez]

Hi, We face the same issue. In a banking context, we have financial instruments with a expiring date far in the future (meaning in 400 years) and some other that have been created 300 years ago. It's not 'infinity', it's just far in the past or futur.