Finally circling back to this one, many thanks for all your comments! Sorry for the long delay, I was sidetracked with a conference and some other things.
To those asking about support for Period or Duration, how would that look like exactly? I reckon we'd need some new constraints along the lines of @MinDuration(value=6000, unit=SECOND)? What would be a use case for validating durations like this? I can somehow see it, but it seems rather specialized to me.
> But if we design the TimeProvider this way, adding something to the method signature won't be possible in the future. However, I don't think this is a real problem. Unless someone comes up with some use case.
It's a good point. I'd dislike adding a parameter object without any properties, "just in case", though. But this is a case where Java 8 default methods are helpful: Should we ever see the need for some context parameter in a subsequent revision, we can add a new method for this and let it delegate to the parameterless one by default.
> If we support the "Year" type, we should also support "YearMonth". This type is not so widely used, but it feels strange to not support it if we support "Year".
Yes, I think you are right.
> Another thing: If @Future and @Past support types like LocalDate, YearMonth and Year, should we perhaps enhance them to allow the user to specify that the "current" year/month/date should also be valid?
That's a very good point, too! This one has been specifically brought up with
https://hibernate.atlassian.net/browse/BVAL-466. It seems sensible to add an annotation parameter for this given the support for these non-instant types. When looking at your example, I'd have a hard time though to reason the exact semantics of inclusive(). I hope we could find something more descriptive?
Btw. Michael (who has been part of the JSR 310 EG) pointed out that TimeProvider should return a Clock.
--Gunnar