I've looked more closely into this:
It seems to be a frequently asked question how to change the displayed date format server-side, e.g.
https://stackoverflow.com/questions/76009630/javascript-to-to-change-input-type-date-format-and-value
https://stackoverflow.com/questions/7372038/is-there-any-way-to-change-input-type-date-format

It seems the consensus is that it cannot be changed server-side (except, of course creating your own widget).
Note that the format that comes back from the date widget seems to be the international format (at least by default) but what the user sees depends *only* on the locale settings in the browser(s).

In Linux we can set the LC_TIME environment variable to force the time format this page:
https://ccollins.wordpress.com/2009/01/06/how-to-change-date-formats-on-ubuntu/
shows how one can define a custom format.

Unfortunately the environment setting seems to be ignored at least by firefox in some versions.

On Windows there is a configuration in the OS where one can configure the time format but it is also by default ignored by some browsers (firefox).

This leads me to believe that the W3C has b0rked the date format and that it is too early to use it in production. Note that I have not seen many web applications using the html native date format. I would have noticed the broken format (I have an us-english locale by default).

So please lets at least make this configurable to use the old widget. It is old-fashioned but at least it does what it should (except for the month-increment bug)

On that note: I have some templates that try to show the full format (including time with seconds) but when I upgrade I'm only seeing a date. The field() method in the html templates by default shows the full date + time, this has changed to only use a date widget.

I noticed this in a simple logging application I wrote for keeping my QSOs as a ham-radio operator (a qso is a two-way radio communication with certain mandatory info transmitted). This shows the full date+time (with seconds) with the old date picker but only the date with the new one. This means by default we break some applications with the new date picker.

The definitions in my qso app look like this:
...Class...
    ... qso_start = Date(), qso_end = Date() 
(so there are no special options)
and in the templates:
<td tal:content="structure python:context.qso_start.field()"/>
(also without any special options)

So my vote would be to make the use of the date picker configurable and make the old format the default -- the new date picker is much nicer but non-functional for many applications. And it does not seem to be widely used due to these problems.