This as already been discussed in the past, (https://hibernate.atlassian.net/browse/ANN-127). Since the support of JodaTime classes, it really makes sens to be able to specify if the annotation is inclusive/exclusive of the current instant/time/date...
For instants it may not be soooo useful, but this is really helpful for non instant date descriptions like LocalDate (but could lead to timezone problems btw...).
My simple usecase is that I have a form with a begin and a end. Both fields are LocalDate with no time. End must be after begin, and end must be either today or in the future. If we are 2013-09-10, the user must be able to select begin=2013-09-10 and end=2013-09-10 for example.
With the current exclusive annotations this is not possible and lead to the creation of a "FutureIncludingNowValidatorForReadablePartial" or a validation through a method.
I don't really know how this behavior can be modified since it's in the javax.validation, perhaps the next version of the specification could be updated?
See original jira: https://hibernate.atlassian.net/browse/HV-820
Yes but these need to be experimented on HV before.
Though the proper way to pass context to validator is not via the validate method but via the validatorFactory.usingContext()...
Ok why not on HV before
Ok I didn't know the validatorFactory.usingContext() as for now we only use a single validator instance which is ok in most cases
In the context of we discussed adding a "resolution" parameter to the constraints: @Past(resolution=Resolution.DAY). The time zone may be injected into the validator via CDI (e.g. via a producer method which returns the time zone from the given user), possibly with falling back to the default (host) time zone if no time zone can be obtained that way.
We definitely can experiment in HV; obviously we can't change the annotations, so we either could add custom constraints (@PastWithResolution) or allow to specify the resolution via another annotation (e.g. @ValidatedDateResolution(Resolution.DAY)) which would then apply to all time constraints of the annotated element, though (in case there are more than one).
Do you think this can be closed now with the introduction of orPresent()?
This issue is fixed, we introduced an orPresent = true attribute to the @Past and @Future annotations.