Support possibility to include the current day/instant and set a resolution in @Future and @Past

Description

Hello,

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?

Environment

None

Activity

Show:
Hardy Ferentschik
September 13, 2013, 7:22 AM

I think the names should be different from @Future and @Past to avoid potential confusion.

+1

> and potentially something like a inclusive flag

What would that do in addition to the resolution parameter?

Maybe nothing. I was just throwing it out there w/o thinking too much about it.

Gunnar Morling
December 23, 2016, 4:21 PM

Hey , do you think that's resolved with your recent work?

Guillaume Smet
December 23, 2016, 5:37 PM

That's one of the 2 JIRA issues I wanted us to discuss (see this comment: https://github.com/hibernate/hibernate-validator/pull/576#issuecomment-263935023).

What is interesting in this proposal is the notion of resolution. I think it's an interesting idea to pursue.

Guillaume Smet
January 26, 2017, 4:10 PM

So we discussed this subject with the expert group.

The status is that we have implemented the orPresent = true feature in BV 2 and HV 6 but we don't see a strong use case for resolution.

Pending someone proposing a valid use case for that, we will close this issue.

Guillaume Smet
October 25, 2017, 9:24 PM

Closing as mentioned in the previous comment. See @PastOrPresent and @FutureOrPresent.

For now, we decided against the resolution.

Assignee

Unassigned

Reporter

SĂ©bastienL

Labels

Feedback Requested

None

Feedback Requested By

None

backPortable

None

Suitable for new contributors

None

Pull Request

None

backportDecision

None

backportReEvaluate

None

Components

Affects versions

Priority

Major
Configure