<div dir="ltr">
<p style="margin-bottom:0in;line-height:100%">Hi Gunnar,</p>
<p style="margin-bottom:0in;line-height:100%">I agree with the
implementation of @Past and @Future with the possibility to customize
the TZ.</p>
<p style="margin-bottom:0in;line-height:100%">The date can be
provided by an external client (e.g. via web service) and it should
be possible to validate it against the timezone of the external
client (e.g. time of payment to a local branch) or the local server TZ (e.g. international transaction).</p>
<p style="margin-bottom:0in;line-height:100%">Personally I don't
see the need to add other types to the validation, they can be easily
converted in other Java types (Month -> Integer etc.) or require
specific use cases (e.g. HijraEra).</p>
<p style="margin-bottom:0in;line-height:100%">Most of the uses
cases that I see ask only the validation of a date (e.g. <span style="line-height:17.8px">@Past </span><span style="line-height:100%">date for an event, @Future date today for a payment) or (less
frequently) date and time.</span></p><p style="margin-bottom:0in;line-height:100%">Cheers</p></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Aug 30, 2016 at 2:39 PM, Gunnar Morling <span dir="ltr"><<a href="mailto:gunnar@hibernate.org" target="_blank">gunnar@hibernate.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Anyone with thoughts/input on supporting the JSR 310 types?</div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">2016-08-25 12:10 GMT+02:00 Gunnar Morling <span dir="ltr"><<a href="mailto:gunnar@hibernate.org" target="_blank">gunnar@hibernate.org</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi,<div><br></div><div>I've pushed another proposal to the website [1], it's about adding @Past/@Future support for the date/time types added in Java 8 (java.time.* package, added by JSR 310). The proposal essentially standardizes the proprietary support we had in HV, plus some additions.</div><div><br></div><div>Please let me know what you think, especially on the questions towards the end. Either put comments inline on the source on GitHub [2] or let's have a discussion here.</div><div><br></div><div>I haven't been using JSR 310 extensively myself, so any feedback by those who have is more than welcome.</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://github.com/beanvalidation/beanvalidation.org/blob/production/proposals/BVAL-496.adoc" target="_blank">https://github.com/beanval<wbr>idation/beanvalidation.org/<wbr>blob/production/proposals/BVAL<wbr>-496.adoc</a></div><div><br></div></div>
</blockquote></div><br></div>
</div></div><br>______________________________<wbr>_________________<br>
beanvalidation-dev mailing list<br>
<a href="mailto:beanvalidation-dev@lists.jboss.org">beanvalidation-dev@lists.<wbr>jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/beanvalidation-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/<wbr>mailman/listinfo/<wbr>beanvalidation-dev</a><br></blockquote></div><br></div>