You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on May 29, 2019. It is now read-only.
I configured the dateFormat for the German style: dd.MM.yyyy
Now when I enter "1.2." it gets parsed as 2nd of January. Expected is 1st of Febuary.
Another example that is pretty confusing for a user:
"1.02.2015" -> February 1st, 2015
"01.02.2015" -> January 2nd, 2015
I already browsed the code a bit and the cause is falling back to new Date(viewValue) which behaves very different across browsers.
Firefox: new Date("1.2.") -> undefined
Chrome: new Date("1.2.") -> Tue Jan 02 2001 00:00:00 GMT+0100 (CET)
Safari: new Date("1.2.") -> undefined
I agree. The fallback to new Date(viewValue) produces some very unexpected behavior. It also seems to use American date formatting (MM/DD/YYYY) which, given that our application is for Australia (DD/MM/YYYY), is almost always not what we want.
I configured the dateFormat for the German style: dd.MM.yyyy
Now when I enter "1.2." it gets parsed as 2nd of January. Expected is 1st of Febuary.
Another example that is pretty confusing for a user:
"1.02.2015" -> February 1st, 2015
"01.02.2015" -> January 2nd, 2015
I already browsed the code a bit and the cause is falling back to new Date(viewValue) which behaves very different across browsers.
Firefox: new Date("1.2.") -> undefined
Chrome: new Date("1.2.") -> Tue Jan 02 2001 00:00:00 GMT+0100 (CET)
Safari: new Date("1.2.") -> undefined
This can be reproduced using the demo datepicker.
I suggest to remove the fallback and to only rely on the DateParser that's part of bootstrap. Or at least to make the fallback optional.
The text was updated successfully, but these errors were encountered: