That is the only sensible format for dates, and while all developers probably agree on that it isn't a given that all your users will.
* 32 CE, if you want to really get down to it
"Just localization" isn't "just". Many people have the wrong localization on their computers. Partly because they don't always communicate in their native language. But also because google et. al. are doing such a piss poor job of it.
It is also always weird if your are on an international site. Enter everything in English and then suddenly is expected to enter some fields in your native language.
You are moving the goalposts.
> "Just localization" isn't "just". Many people have the wrong localization on their computers.
Think about this for a minute longer. Do you have an example or scenario for the use of a Web site where the author can fall into a pit of success (despite having the user's wrong localization) on all things except for dates and that would be broken by allowing* this date input method?
Even ignoring that:
What I said was that "any permutation of full year, full month name, and day of the month is unambiguous". There are a finite number of months and a finite number of localized tokens for representing those months. Do you have an example of two different locales that use the same token (or token sequence) to denote different months on the calendar?
* the word "allowing" playing a crucial role here
If you are using a proleptic Gregorian (or Julian, but why on earth would you do that) calendar, sure.
If its not one of those (but its still the Roman-derived Christian calendar in some form), there are ambiguities, and if its any other calendar, it may have ambiguities and/or the elements needed to specify a date may be different, and the CE/AD year is likely not an element and not relevant to whethe or not their are ambiguities.
I put in a whole clause in my original comment to preempt this flavor of pedantic sniping that involves applying double standards. And yet here we are.