> 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.

> 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.