<div dir="ltr">Thanks a lot for your feedback!<div><br></div><div>On 1., I was initially a bit skeptical about @Future for partial types such as LocalTime or MonthDay, which don't denote "one point in time" but a recurring one. But after playing a bit with those types in the RI, having support for them felt alright.</div><div><br></div><div>On 2., agreed. People can always put their constraint to a derived member with the right resolution as pointed out by Michael, so I don't think it warrants explicit support.</div><div><br></div><div>On 3., ok, works for me.</div><div><br></div><div>Based on this feedback and the original proposal [1]. I've sent a pull request for updating the spec (<a href="https://github.com/beanvalidation/beanvalidation-spec/pull/122" target="_blank">https://github.com/<wbr>beanvalidation/beanvalidation-<wbr>spec/pull/122</a>). Note that you need to take a look at the API project, too, in order to get the full picture (as we include API types directly from there). </div><div><br></div><div>Any comments on this change are welcome. I'll leave the PR open until the end of the week end then merge it if nothing more comes up.</div><div><br></div><div>This change does not include support for range data types, I've opened BVAL-553 [2] for that one. @Michael, maybe you are up for writing a proposal for that one, too?<br></div><div><br></div><div>Thanks,</div><div><br></div><div>--Gunnar</div><div><br></div><div>[1] <a href="http://beanvalidation.org/proposals/BVAL-496/" target="_blank">http://beanvalidation.org/<wbr>proposals/BVAL-496/</a></div><div>[2] <a href="https://hibernate.atlassian.net/browse/BVAL-553">https://hibernate.atlassian.net/browse/BVAL-553</a></div><div><br></div><div><br></div><div class="gmail_extra"><br><div class="gmail_quote">2017-01-08 12:43 GMT+01:00 Christian Kaltepoth <span dir="ltr"><<a href="mailto:christian@kaltepoth.de" target="_blank">christian@kaltepoth.de</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hey all,<div><br></div><div>see my thoughts inline..</div><div><br></div><div><br><div class="gmail_extra"><div class="gmail_quote"><span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div class="gmail_extra"><div class="gmail_quote"><span class="gmail-m_-7256207416813679458m_8587760826936362951gmail-"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);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></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></blockquote></span></div></div></div></div></blockquote><div> </div></span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div class="gmail_extra"><div class="gmail_quote"><span class="gmail-m_-7256207416813679458m_8587760826936362951gmail-"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);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></div><br></div><span>We tried to think of a use case but couldn't think of any.<br></span></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></blockquote><div><br></div></span><span><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><span class="gmail-m_-7256207416813679458m_8587760826936362951gmail-"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);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></span><div>Consistency for me is a good argument in itself. If we couldn't think of the use case, maybe it's just because we're temporarily blind. Being consistent doesn't hurt, especially given the effort is minimum :-)</div></span></div></div></div></div></blockquote><div><br></div><div>I agree with Michael. I could imagine use cases especially in the context of financials (just think of a fiscal year for example). So I would prefer to be consistent and just support it.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="gmail-m_-7256207416813679458m_8587760826936362951gmail-"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>2. Resolution<br>==========<br>[...]<br></div><span><div><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></span></div></blockquote><div><br></div></span><span><div>While this is a valid use case, it seems a little bit specific to me in the sense you have a reference for "now" 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 "truncation" (which is just a specific case of conversion) to ChronoUnit, when other types of conversion might be needed.</div></span></div></div></div></blockquote><div><br></div><div>I don't think this is a very common use case. So I currently don't see a good reason to support it. But may be I'm missing a common use case here?</div><div><br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div class="gmail_extra"><div class="gmail_quote"><span class="gmail-m_-7256207416813679458m_8587760826936362951gmail-"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div><div><div><div><div><div>3. orPresent<br></div>=========<br>[...]</div></div></div><br></div><span>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.<br></span></div></div></div></blockquote><div><br></div></span><span><div>I vote for one annotation.</div></span></div></div></div></div></blockquote><div><br></div><div>I would also prefer one annotation. I think even something like @Past(resolution = DAY, orPresent = true) is quite good readable.</div><span class="gmail-m_-7256207416813679458HOEnZb"><font color="#888888"><div><br></div><div><br></div><div>Christian</div></font></span></div><span class="gmail-m_-7256207416813679458HOEnZb"><font color="#888888"><br clear="all"><div><br></div>-- <br><div class="gmail-m_-7256207416813679458m_8587760826936362951gmail_signature"><div>Christian Kaltepoth</div><div>Blog: <a href="http://blog.kaltepoth.de/" target="_blank">http://blog.kaltepoth.de/</a></div><div>Twitter: <a href="http://twitter.com/chkal" target="_blank">http://twitter.com/chkal</a></div><div>GitHub: <a href="https://github.com/chkal" target="_blank">https://github.com/chkal</a></div><div><br></div></div>
</font></span></div></div></div>
<br>______________________________<wbr>_________________<br>
beanvalidation-dev mailing list<br>
<a href="mailto:beanvalidation-dev@lists.jboss.org" target="_blank">beanvalidation-dev@lists.jboss<wbr>.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/beanvalidation-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailma<wbr>n/listinfo/beanvalidation-dev</a><br></blockquote></div><br></div></div>