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
Is your feature request related to a problem? Please describe.
I'm always frustrated when I type in a valid date, but the input is silently rejected and reverts to it's previous value.
For example, if the date format is set to d/m-Y and I type in 1-1-2025, the input is silently rejected, because I used a different separator - even though the date as such is unambiguously valid.
The idea that users will use the exact date separators specified by an application, unfortunately, is not true. In many countries, there is no universally agreed-upon date/time format - different applications use different format, and so, in practice, people are going to use whatever separator they feel like. The user experience of not even highlighting the input as invalid, and instead silently reverting to the previous value, is not really great.
To be clear, I am describing two compounding problems here: that of not accepting valid input because of strict separator requirements, and that of silently rejecting the user's input without any clear indication.
Describe the solution you'd like
I would suggest two changes to improve the user experience:
Accept literally any non-numeric separators as separators: for example, if the format is d/M-y HH:ss, accept input such as 1-2/2025 5:50 and simply correct it to 1/2-2025 05:50 by replacing the placeholders (and adding missing zero padding) when I tab out of the input.
If the entered date/time itself is invalid (year/month/day/hour/minutes out of range) do not silently revert to previous input: instead, preserve the value in the input and flag it as invalid. (the input state is different from the actual value - form inputs in general don't just update themselves to a different value. as a user, I would expect to be able to correct my input, rather than having it silently get thrown away.)
Describe alternatives you've considered
I could use the customInput feature, which is what I'm currently exploring. I'm not completely sure this is possible, but since nothing else I've treid comes close to good UX, I'm attempting it.
Either way, I think it would be nice for everyone if improvements to the overall user experience were applied to the library itself, providing better default behavior for everyone, so I might be willing to go one step further and apply these improvements to the library itself - if there is any interest?
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem? Please describe.
I'm always frustrated when I type in a valid date, but the input is silently rejected and reverts to it's previous value.
For example, if the date format is set to
d/m-Y
and I type in1-1-2025
, the input is silently rejected, because I used a different separator - even though the date as such is unambiguously valid.The idea that users will use the exact date separators specified by an application, unfortunately, is not true. In many countries, there is no universally agreed-upon date/time format - different applications use different format, and so, in practice, people are going to use whatever separator they feel like. The user experience of not even highlighting the input as invalid, and instead silently reverting to the previous value, is not really great.
To be clear, I am describing two compounding problems here: that of not accepting valid input because of strict separator requirements, and that of silently rejecting the user's input without any clear indication.
Describe the solution you'd like
I would suggest two changes to improve the user experience:
d/M-y HH:ss
, accept input such as1-2/2025 5:50
and simply correct it to1/2-2025 05:50
by replacing the placeholders (and adding missing zero padding) when I tab out of the input.Describe alternatives you've considered
I could use the
customInput
feature, which is what I'm currently exploring. I'm not completely sure this is possible, but since nothing else I've treid comes close to good UX, I'm attempting it.Either way, I think it would be nice for everyone if improvements to the overall user experience were applied to the library itself, providing better default behavior for everyone, so I might be willing to go one step further and apply these improvements to the library itself - if there is any interest?
The text was updated successfully, but these errors were encountered: