<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"><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-"><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><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-"><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>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></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-"><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&#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></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-"><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><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></div></blockquote><div><br></div></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 &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></div></div></blockquote><div><br></div><div>I don&#39;t think this is a very common use case. So I currently don&#39;t see a good reason to support it. But may be I&#39;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-"><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>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></span><div>I vote for one annotation.</div></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><div><br></div><div><br></div><div>Christian</div></div><br clear="all"><div><br></div>-- <br><div class="gmail_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>
</div></div></div>