We tried to think of a use case but couldn't think of any.The implementation we committed indeed supports MonthDay by building a MonthDay from the Clock provided by the ClockProvider and comparing them using MonthDay.compare(...).While @Past and @Future make sense for YearMonth, it's a bit more difficult to define them for MonthDay.The initial proposal of Michael included the support for partials such as YearMonth or MonthDay (ie types which do not strictly represent a point in time).================1. Support for partials
That being said, it does not cost us anything to have it for consistency.
2. Resolution
==========In the comments of https://hibernate.atlassian.net/browse/HV-820 , someone suggested the idea of resolution.You could have something like:@Future(resolution = ChronoUnit.MONTHS)private LocalDate paymentDate;This would truncate the LocalDates to ChronoUnit.MONTHS before doing the comparison, ensuring that the date should be at least next month.
Note that it's only useful if you use a type more precise than what you require for the validation so it might be a very narrow use case not worth adding additional complexity to the standard constraints.
Personally, I prefer having one annotation with an option rather than 2 different annotations - I think it has a better semantic - but I can see the rationale behind Gunnar's proposal.Something like @Past(resolution = DAY, orPresent = true) would be less readable than @PastOrPresent(resolution = DAY).The current implementation adds orPresent support as an option of the preexisting @Past/@Future annotations:3. orPresent=========@Past(orPresent = true) / @Future(orPresent = true)Gunnar suggested this afternoon that it might be more readable to have @PastOrPresent/@FutureOrPresent, especially if we have more than one options for @Past/@Future.