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.
This is a feature request to make the date parser more tolerant.
If a user enters a date by hand it would be nice to be more tolerant. E.g. I set the dateFormat to dd.MM.yyyy it would be nice for all of these to be accepted as Feb, 1st 2014:
a) 01.02.2014
b) 1.2.2014
c) 1.2.14
d) 1.2.
Currently only a is parsed correctly. I would say b is really useful and c and d are nice-to-have.
I understand that the tolerant parsing is only possible when a separator is available. Parsing yyyyMMdd in this way does not seem useful.
(A related bug is #2508: Chrome would parse b,c and d as Jan, 2nd).
+1 👍
I have the same issue with European users because their date format is in most cases "dd.MM.yyyy". It's pretty wired for them to get their date interpreted like "MM/dd/yyyy"
For me it would be very great if there is a differentiation between the separators "." and "/".
so "01.02.2014" results in 1st Feb 2014
and "01/02/2014" results in 2nd Jan 2014
This would be really great!
This is a feature request to make the date parser more tolerant.
If a user enters a date by hand it would be nice to be more tolerant. E.g. I set the dateFormat to
dd.MM.yyyy
it would be nice for all of these to be accepted as Feb, 1st 2014:a) 01.02.2014
b) 1.2.2014
c) 1.2.14
d) 1.2.
Currently only a is parsed correctly. I would say b is really useful and c and d are nice-to-have.
I understand that the tolerant parsing is only possible when a separator is available. Parsing
yyyyMMdd
in this way does not seem useful.(A related bug is #2508: Chrome would parse b,c and d as Jan, 2nd).
Can be reproduced using the demo datepicker
The text was updated successfully, but these errors were encountered: