datepicker: shows date using provided LOCALE_ID but parses date using default US locale (or a combination of them)

[relair]

Bug, feature request, or proposal:

Bug. I don't think it is working like that on purpose.

What is the expected behavior?

Date picker uses provided en-GB LOCALE_ID for parsing typed in date - 27/10/2018 input manually by typing is valid

What is the current behavior?

Typed date is parsed using US locale - 27/10/2018 input manually is invalid, 12/01/2018 is December, not January.

What are the steps to reproduce?

https://stackblitz.com/edit/angular-datepicker-locale?file=main.ts

1. Select 27/10/2018 using date picker.
2. Modify the date by editing the input to 26/10/2018
3. Observe invalid input

What is the use-case or motivation for changing an existing behavior?

Make material datepicker great again! But seriously: it seems like if a culture is provided it should affect both parsing and formatting aspects of dealing with dates and not format it into a date which is considered invalid when updated by typing.

Which versions of Angular, Material, OS, TypeScript, browsers are affected?

As in demo: Angular 7.1.0 Material 7.1.0. It fails validation on chrome if day (month?) is over 12, but on IE 11 is more curious as it modifies the year, I am fairly sure the swap issue causes it to work incorrectly on any browser.

Is there anything else we should know?

I think it may have been an issue with parsing the text date from text - it seems like it would parse using US culture ignoring provided locale.

[manklu]

Have a look at the documentation https://material.angular.io/components/datepicker/overview

Especially the chapter "Choosing a date implementation and date format settings"

[mmalerba]

Closing as this is a limitation of JavaScript's native parsing. I'd recommend using a different DateAdapter as suggested above

[relair]

Why use native parsing by default if its so bad? So I need to use a workaround to make it working properly as it wouldn't work on different cultures by default? Why is datepicker picking culture settings knowing that it wouldn't work for them properly anyway?
So you just close the obvious bugs just because there is a workaround and you can't be bothered to fix them? If I known that I wouldn't start using this library in the first place...

[mmalerba]

People have different needs for different apps, we don't want to mandate a heavy-weight dependency for people that don't need it. We provide both a NativeDateAdapter and a MomentDateAdapter and people are free to write additional adapters if that's what they need for their use case

[relair]

I don't understand why would you use locale for displaying date but not for parsing, so you knowingly make it format date using one format and parse it using the other format? Would make more sense to have native provider not pick up locale settings at all if you cannot make it work both ways.
For parsing you only have new Date(Date.parse(value))
which understandably requires date in specific format which may or may not be consistent with Locale settings (most of the time it is not, unless you use US locale)

My suggestion is rather than obscuring the parsing issue make it apparent that NativeDateAdapter doesn't support locales and get rid of it for formatting dates, as you cannot make it work without overhead of making sure you provide the right format to Date.parse (which is pretty much what moment covers for you).

[relair]

I saw the note in the documentation

Please note: MatNativeDateModule is based off of the functionality available in JavaScript's native Date object, and is thus not suitable for many locales.

At the point how it works right now it should be in bold red text at the top of the page, not hidden among some details. Look at it from perspective of a developer(user) using your library:

1. User already has locale setup in angular
2. User installs material library and puts a date picker on his page without setting anything else, noticing it is using his locale format
3. User finds a bug as although date picker displays format in his locale it doesn't parse the typed in date in the same format as expected.

I think it should work consistently 'out of the box' (as nothing was setup for it specifically - even the locale wasn't set at this point as MAT_DATE_LOCALE just inherited generic one). Then you can do some setup, for example to have custom date format you may want to look into different date adapters and some detailed configuration documentation.
Right now it looks like when you just happen to have a locale setup it won't work consistently by default, and that is what this bug is about.
So instead of

Date picker uses provided en-GB LOCALE_ID for parsing typed in date - 27/10/2018 input manually by typing is valid

You can make it

Date picker has consistent date format between parsing and formatting

[mmalerba]

I'll reopen this as a docs issue

[Poseclop]

+1 on that one as the current behavior is unexpected and ended up as a bug in our dev branch (highly critical as it does not throw any exception yet potentially has our customers looks at the wrong data).

• Expected behavior is that manual input in DatePicker would be parsed using the local that was setup.
• Understand the "Date" limitations but we should add a big red flag in documentation to avoid confusion.

Thanks. Keep up the good work.