There is datetime-local, date, and time. And there's a lot of control over what is allowed with min-max ranges, steps, etc.
The only thing I can imagine to go wrong here, is when a user has their browser set in US-en but when they are not aware of that. Which seems... weird; or at least not a problem a web-dev should solve.
> Lets you enter nonexistent dates like 31/2
This may be an issue in specific browsers/versions/os. But enabling the "validation" by setting required and/or some other attributes, gives an error for these dates AFAICS. But, in any and all cases: server-side validation is needed anyway. You just cannot trust a value sent by a user, whether that's "validated" with sixty npm-packages and their dependencies, or by the browser.
Legacy Edge used to look at keyboard locale and ignore the actual region settings. I have no idea why chromium uses MM/DD on my machine when Firefox does DD/MM. Back when $COMPANY used HTML date widgets we got a small but constant stream of complaints which we tried to triangulate (that's how I know about the Legacy Edge behaviour), but we never understood most cases.
Autodetection has been broken on a tail edge of cases for a long long time, and nobody in browser space seems to have any interest in fixing this - or worse, allowing the server to set the correct date style. The only practical fix is JS datetime widgets.
>or at least not a problem a web-dev should solve.
I think 'a not-insignificant amount of people constantly enters the wrong dates and eventually bothers support and writes bad reviews, plz fix this' is a good business cases and is something web-dev should try to handle.
>> Lets you enter nonexistent dates like 31/2
>server-side validation is needed anyway.
True, but it's a better user experience to disallow this also on client. If we only let the server do validation, why do we even bother with the SPA and the sixty-thousand one-line npm packages?
Which is another reason to let browsers - the user agents - deal with this. There's absolutely no way a lonely JS dev, or even a community around something like MUI to get all this right. And they don't. There's always something broken for me with these custom elements. If it's not some US-centric web-app enforcing their MM/DD/YYYY format, then it's some "ignorant" dev being unaware that in Europe in many countries decimal separators are a comma, or that in Thailand the current year is 2566 and that this is not "too far in the future".
LC_TIME does not work very well with most apps.
And there is a big difference between just throwing an error if a date-time cannot be parsed because of a nonextent date, and communicating it to the user in a nice way, especially without using JS.
* Lets you enter nonexistent dates like 31/2
* Can and often does accidentally place the user in American-style MM/DD format where it should be European-style DD/MM (I have a replicable case now on that page example).
* No ability to force date style by design. So there's no way to fix the above from the server, or to use ISO-style dates. Only way to reliably prevent MM/DD by default is to fix every client configuration - not very likely even in small companies.
* No way to have the datetime dialog open by default.
* Poorish but getting better keyboard support (the pagedown-up keys finally work in most browsers, but once you've opened the dialog you can't enter a new date with the keyboard).
* Timezones must be handled separately, which is just poor design.
(Entire list checked on desktop)