Datepicker manual input forced to US format

[natcohen]

Hello,
I'm using datepicker with input (so the user can insert the date manually). If I select in the datepicker the date, it will show up with format dd.MM.yyyy (which is what I want). But if I manually write inside the input, the datepicker popup won't be set to the correct date and will shoow US format date (MM.dd.yyyy).

you can try there:
http://plnkr.co/edit/t9ERna33YcG8ubDqDPgy?p=preview

[natcohen]

Is this issue still open or did you completely fix it?

[sphinks13]

my pull request fixes this issue but it still isn't merged.

[natcohen]

Why is this bug still not fixed in version 0.12??? What can I do so it gets fixed in the next version?

[chrisirhc]

Do you mean that if you type 1.12.1987, you expect 1 December 1987 to be selected? I see the correct result when I type 01.12.1987.

It looks like this issue is that the date parser is too strict and expects 2 digits in the days. #2395 doesn't solve the root of the problem. After merging that, it will instead show that 1.12.1987 is an invalid date input.

[chrisirhc]

After reading the dateParser, I found that all you need to do is to change the format to d.M.yyyy instead. That should have your intended behavior. Try typing 1.12.1987 or 1.5.1987 in the following Plunker:

http://plnkr.co/edit/t7dZjLDr5pA2x4NDV4M4?p=preview

[natcohen]

The behavior is not consistent and the result can be misinterpreted. When the format is dd.MM.yyyy inputs such as: 01.12.87, 1.12.1987, 1.12.87, 1.5.1987 or 1.5.87 should either return an error (not ideal but at least consistent!) or interpret it as d.M.yyyy, d.M.yy etc... The order should be a priority!

[natcohen]

@chrisirhc Any news on this issue?

[wesleycho]

I believe this is currently fixed on master with making the model invalid - feel free to open a new issue if this is not the case