(Experience) DatePicker: experience for culture based format is not very good

[anranruye]

Is your feature request related to a problem? Please describe.

Culture based format is introduced since #1389 . It's nice to display the date in format based on cultureInfo. But for input, it's not
always good to use the same format. For example, a Chinese date string is like "2021年5月24日" (年=year, 月=month, 日=day). It's easier to just input "2021-5-24" than the chinese characters, but when we try to input "2021-5-24", this string is not parsed.

Describe the solution you'd like

Besides culture-based format, we should always support standard/basic formats("yyyy-MM-dd", "yyyy/MM/dd", etc.) when input the date manully.

Additional context

Add any other context or screenshots about the feature request here.

[anddrzejb]

As the author of #1389, I do get cold feet here. This whole culture matching when typing was more painful than I would like to admit. Having said that, I absolutely can see utility in your proposal. After all this lib should make life easier for both developers and end users.
My second thought after I read the proposal (first being "God, nooo" 😉) was that maybe we should introduce something like AlternateEntryFormat parameter? This would only address entering but not viewing. It could either be a string or array of strings, where index could represent the priority, with current culture being first in the list of priorities.

[anranruye]

maybe we should introduce something like AlternateEntryFormat parameter? This would only address entering but not viewing. It could either be a string or array of strings, where index could represent the priority, with current culture being first in the list of priorities

Sounds good to me.