<div dir="ltr"><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div>Hi and happy new year to everyone!<br><br></div>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.<br><br></div>1. Support for partials<br>================<br><br></div>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).<br><br></div>While @Past and @Future make sense for YearMonth, it&#39;s a bit more difficult to define them for MonthDay.<br><br></div>The implementation we committed indeed supports MonthDay by building a MonthDay from the Clock provided by the ClockProvider and comparing them using MonthDay.compare(...).<br><br></div>We tried to think of a use case but couldn&#39;t think of any.<br><br></div>Partials currently supported are:<br></div>- LocalTime<br></div>- MonthDay<br></div>- OffsetTime<br></div>- Year<br></div>- YearMonth<br><br></div>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&#39;t find any potential use case and it looks just weird.<br><br></div>That being said, it does not cost us anything to have it for consistency.<br><br></div>So, any thoughts on this? Use cases, votes for removing it/keeping it?<br><br></div>2. Resolution<br>==========<br><br></div><div>In the comments of <a href="https://hibernate.atlassian.net/browse/HV-820">https://hibernate.atlassian.net/browse/HV-820</a>, someone suggested the idea of resolution.<br><br></div><div>You could have something like:<br><br></div><div>@Future(resolution = ChronoUnit.MONTHS)<br></div><div>private LocalDate paymentDate;<br><br></div><div>This would truncate the LocalDates to ChronoUnit.MONTHS before doing the comparison, ensuring that the date should be at least next month.<br><br></div><div>It might also be useful to reduce the resolution of ZonedDateTimes to days before doing the comparison, especially when using the orPresent option.<br><br></div><div>Note that it&#39;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.<br></div><div><br></div><div>Do you see any use cases for that? Have you ever used custom constraints for that?<br></div><div><br></div>3. orPresent<br>=========<br><br></div>The current implementation adds orPresent support as an option of the preexisting @Past/@Future annotations:<br></div><div>@Past(orPresent = true) / @Future(orPresent = true)<br></div><div><br></div>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.<br><br></div>Something like @Past(resolution = DAY, orPresent = true) would be less readable than @PastOrPresent(resolution = DAY).<br><br></div>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&#39;s proposal.<br><br></div>Thoughts?<br><br></div><div>Thanks.<br></div><div><br>-- <br></div>Guillaume<br></div>