mui
[pickers] Allow to have infinite valid dates (no minDate, no maxDate)
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:
- Type
12/31/2099. Open the popover. Observe that the right arrow (to navigate to January 2100) is disabled. - 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
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?
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).
(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.
@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)?
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.
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.
I also have a need to go beyond the min and max set on the datepicker. My use case is a historical data site which you can set birth and death dates of real historical figures. I know that BC dates are tricky so I dont expect it to go that far back - but would love to find a date picker that did!
Also I dont want to limit my site to real entities so I want users to be able to choose any date in the future. If this is not possible with MUI Date picker - any other suggestions or work arounds?
We also need to go beyond the current limit of the dates. We have some users that work with nuclear energy and need to be able to set dates far into the future (at least to year 2999). Some other date pickers seem to be able to handle dates up to year 9999 such as react date picker and day picker
Order ID: 99756
