<div dir="ltr">Hi Guillaume,<div><br></div><div>Let me see if I can help:<br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jan 5, 2017 at 2:58 PM, Guillaume Smet <span dir="ltr">&lt;<a href="mailto:guillaume.smet@gmail.com" target="_blank">guillaume.smet@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><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>1. Support for partials<br></div></div>================<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></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></blockquote><div><br></div><div>When you are using a calendar year for fiscal purposes (in Brazil, its January-December), you could use MonthDay to represent a point in time separately from the year. If a MonthDay represents a holiday, there might be other use cases related to the current year.</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div><div><div><div><div><div><div><br></div>That being said, it does not cost us anything to have it for consistency.<br></div></div></div></div></div></div></div></div></div></div></blockquote><div><br></div><div>Consistency for me is a good argument in itself. If we couldn&#39;t think of the use case, maybe it&#39;s just because we&#39;re temporarily blind. Being consistent doesn&#39;t hurt, especially given the effort is minimum :-)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div><div><div><div>2. Resolution<br>==========<br><br></div><div>In the comments of <a href="https://hibernate.atlassian.net/browse/HV-820" target="_blank">https://hibernate.atlassian.<wbr>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></div></div></div></div></div></div></div></div></blockquote><div><br></div><div>While this is a valid use case, it seems a little bit specific to me in the sense you have a reference for &quot;now&quot; as a comparison (a use case I mentioned before is validating a temporal object against an arbitrary reference) and in this case converting it. This also limits the &quot;truncation&quot; (which is just a specific case of conversion) to ChronoUnit, when other types of conversion might be needed.</div><div><br></div><div>This can be handled by doing:</div><div><br></div><div>@Future</div><div>private YearMonth paymentYearMonth() {</div><div>    return YearMonth.from(paymentDate);</div><div>}</div><div><br></div><div>Which is trivial. </div><div><br></div><div>A more interesting use case that remains unsupported, of which the previous is kind of a specialization is: I have a startDate and an endDate and there is no simple way to express that endDate must be greater or equal than startDate. That would apply to any Comparable, by the way :-( If we are to pursue something more advanced, that&#39;s the use case I&#39;d suggest going after.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div><div><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></div></div></div></div></div></div></blockquote><div><br></div><div>That&#39;s my opinion, too narrow. A broader one is relative comparable validation.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div><div><div><div>3. orPresent<br></div>=========<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/@<wbr>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></div></div></div></blockquote><div><br></div><div>I vote for one annotation.</div><div><br></div><div>PS: sorry for my long absence. My work load got too intense these days, I hope it will cool off soon... </div><div><br></div><div>Regards,</div><div>Michael</div></div></div></div></div>