11:53 p.m.
Hey all,
I just reviewed the proposal in more detail. I really like it. Great work.
Some comments:
*Make current time and timezone customizable*
I also don't see a use case for making the retrieval more contextual. But
if we design the TimeProvider this way, adding something to the method
signature won't be possible in the future. However, I don't think this is a
real problem. Unless someone comes up with some use case.
*Other JSR 310 types to support*
If we support the "Year" type, we should also support "YearMonth".
This
type is not so widely used, but it feels strange to not support it if we
support "Year".
Another thing: If @Future and @Past support types like LocalDate, YearMonth
and Year, should we perhaps enhance them to allow the user to specify that
the "current" year/month/date should also be valid? I'm thinking of
something like:
@Past( inclusive=true )
private LocalDate someDate; // valid if someDate <= today
Thoughts?
Christian
2016-09-01 12:40 GMT+02:00 Otávio Gonçalves de Santana <otaviojava(a)java.net>
:
Period or Duration is a good idea. Once it's Java 8 and BV 2.0
will
support it. IMHO makes sense has support to it.
On Thu, Sep 1, 2016 at 7:14 AM, Hendrik Ebbers <hendrik.ebbers(a)me.com>
wrote:
> I like the the proposal :)
> Currently it do not support new data types like Period or Duration
> (implementations of TemporalAmount). But for this types new annotations /
> constraints are needed. The question is if this should be supported by the
> JSR, too.
>
> Am 30.08.2016 um 14:39 schrieb Gunnar Morling <gunnar(a)hibernate.org>:
>
> Anyone with thoughts/input on supporting the JSR 310 types?
>
> 2016-08-25 12:10 GMT+02:00 Gunnar Morling <gunnar(a)hibernate.org>:
>
>> Hi,
>>
>> 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.
>>
>> 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.
>>
>> I haven't been using JSR 310 extensively myself, so any feedback by
>> those who have is more than welcome.
>>
>> Thanks,
>>
>> --Gunnar
>>
>> [1] http://beanvalidation.org/proposals/BVAL-496/
>> [2] https://github.com/beanvalidation/beanvalidation.org/blo
>> b/production/proposals/BVAL-496.adoc
>>
>>
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>
>
>
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>
--
Otávio Gonçalves de Santana
twitter: http://twitter.com/otaviojava
site: *http://about.me/otaviojava <http://about.me/otaviojava>*
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
--
Christian Kaltepoth
Blog: http://blog.kaltepoth.de/
Twitter: http://twitter.com/chkal
GitHub: https://github.com/chkal