I think this omission probably comes down to having a database centric view of the possiblilities. In the docs I see that the effect of @Past is:
property (date or calendar)
check if the date is in the past
Add a check constraint on the column
Obviously one would not want a @Future annotation to create a database check constraint. However, for something like a CreditCard object, adding @Future to the expirationDate property would be useful. Even if a creditCard is loaded from the database, we can still identify that it is no longer valid. Again it boils down to the big picture. Data going into the persistence storage should always be valid. Do we make the assumption that all data being loaded from storage is also valid with respect to our Validation annotations?
Another enhancement for both @Past and @Future would be a boolean attribute indicating whether the validation would consider the present day as a valid entry.
Hibernate 3.1 rc2, Annotations 3.1 Beta 6
Nice idea. Provide a patch, I'll apply it.
Done, I'm concerned by the day after etc, cause it imply something much more complex like day comparison, month comparison, year comparisone etc.
Currently this is only ms comparison.
So, if you think it's a real use case, then open a new case and let's start to think about it.