fix: add client-side validation for @PastOrPresent and @FutureOrPresent #8684
Conversation
|
I think this implementation is not really useful for real use cases. Proper way imo would be to check the resolution of the date value (in this case see does the date string contain hours, minutes, seconds etc.) and then create the comparison date and convert that to the same resolution so e.g. by dropping time of day if the original value only has a date but no time. And then the comparison needs to be done with Then it would be possible to have e.g. date picker where the value doesn't have a time and "present" would match the date of today in all cases. |
Client-side validators interpret 'present' as 'within one second of _now_'. NOTE: JSR-380 server-side validators interpret 'present' depending on the Java property type (could be the whole current year for `java.time.Year` (see https://beanvalidation.org/2.0-jsr380/spec/#builtinconstraints-pastorpresent)
…OrPresent It's not trivial to ensure the same granularity of _present_ as on the server-side: year / month / day / minute. Until there is a sensible client-side implementation that works close enough to the server-side, it's better not to have any client-side validation for these constraints than to have a broken implementaiton.
vlukashov
force-pushed
the
vl/fix/add-missing-validators-impl
branch
from
b3e559d
to
0793bfc
Compare
|
SonarQube analysis reported 1 issue Note: The following issues were found on lines that were not modified in the pull request. Because these issues can't be reported as line comments, they are summarized here:
|
Client-side validators interpret 'present' as 'within one second of now'.
NOTE: JSR-380 server-side validators interpret 'present' depending on the Java property type (could be the whole current year for
java.time.Year(see https://beanvalidation.org/2.0-jsr380/spec/#builtinconstraints-pastorpresent)