[bv-dev] Improved java.time support follow-up

Hi and happy new year to everyone! We discussed a couple of things today with Gunnar and we have a couple of questions for you all regarding the improved java.time support we committed before the holidays. 1. Support for partials ================ 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). While @Past and @Future make sense for YearMonth, it's a bit more difficult to define them for MonthDay. The implementation we committed indeed supports MonthDay by building a MonthDay from the Clock provided by the ClockProvider and comparing them using MonthDay.compare(...). We tried to think of a use case but couldn't think of any. Partials currently supported are: - LocalTime - MonthDay - OffsetTime - Year - YearMonth I think Year and YearMonth can be considered OK without further discussion. LocalTime and OffsetTime, I can think of use cases. MonthDay, well, I didn't find any potential use case and it looks just weird. That being said, it does not cost us anything to have it for consistency. So, any thoughts on this? Use cases, votes for removing it/keeping it? 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. It might also be useful to reduce the resolution of ZonedDateTimes to days before doing the comparison, especially when using the orPresent option. 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. Do you see any use cases for that? Have you ever used custom constraints for that? 3. orPresent ========= The current implementation adds orPresent support as an option of the preexisting @Past/@Future annotations: @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. Something like @Past(resolution = DAY, orPresent = true) would be less readable than @PastOrPresent(resolution = DAY). 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. Thoughts? Thanks. -- Guillaume