[cxr]

As input, any permutation of full year, full month name, and day of the month is unambiguous wrt any date on or after January 1, 100 CE* and therefore sensible, no matter how unusual/obscure. (The issue of handling multiple languages isn't a rejoinder to this, because that's just localization, which is an umbrella that should already exist so treating it like a new requirement would just be double counting.) This is how every browser-native datepicker should already work, although regretfully they do not.

* 32 CE, if you want to really get down to it

[tjoff]

Noone would expect that so you'd need to explain it and get people to spell correctly. Not convinced it is a good UX.

"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.

[cxr]

> Noone would expect that

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

[dragonwriter]

> As input, any permutation of full year, full month name, and day of the month is unambiguous wrt any date on or after January 1, 100 CE* and therefore sensible, no matter how unusual/obscure

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.

[cxr]

The comment I replied to specified ISO 8601. The Gregorian constraint is a given.

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.

[pacaro]

Only if you use a proleptic calendar. If you are entering dates from historic documents, you need to know which calendar the author of the document was using

[cxr]

Did you read my comment in the parenthetical?

[pacaro]

Did you ever try `cal 9 1752`

[cxr]

What about it?