We had a proposal to do an automatic conversion of the strftime to Date format in the past. It didn't work well.
I'm not a fan of doing such automatic conversion, but it will be better than nothing.
Main thing to do is imho to rewrite the calendar so it doesn't use the strftime format anymore (if it still does). And then the calendar formfield can be rewritten to only use the Date formatstring (that one already exists in the language pack).

Like, why would you select a Date and then only show the month name?! you wouldn't

Famous last words...

FWIW if @Bakual is ok I'm more than happy with the changes

@PhilETaylor only when php dates support all non gregorian calendars

looking forward to your rewrite that for Joomla 5 that allows us to break b/c and use PHP dates ;-)

As I wrote in the other issue 2022 will be the year that all browsers will roll temporal: https://github.com/tc39/proposal-temporal (implemented behind a flag already in a few). I don't know if I will be the one that will rewrite the calendar but once that piece of code is available (actually it is right now with a polyfill...) the calendars will be way easier than the current thing...

Current PR is okay as temporary solution.

only when php dates support all non gregorian calendars

@brianteeman it can, try this:

$formatter = new \IntlDateFormatter('fa_IR', \IntlDateFormatter::LONG, \IntlDateFormatter::NONE);
echo $formatter->format(time());

It just not easy to integrate to the api we have. It should be something new (kind of calendar2 field).

For proper date format we need to think about PHP Intl date formater for server side and "temporal js" for client side.
They both based on ICU (if I right understood).
They will have common pattern format, but different from date(), strftime(). https://unicode-org.github.io/icu/userguide/format_parse/datetime/
For general use should be enough default patterns SHORT, MEDIUM, LONG.

And with it we should drop the translations for patterns in the inputs, it a horror.

For proper date format we need to think about PHP Intl date formater for server side and "temporal js" for client side.

YES, I totally agree here.

A (probably radical) idea: PHP should only (by default) deal ONLY with the SQL format (also the JS part should also return SQL formatted datetime string). That would simplify immensely the code. A quick explanation: the PHP should NOT be used to directly handle input from the UI (that's the JS's part), thus handling only one default format is totally fine.

It seems works, on quick test,
You also have to update it here: