[bv-dev] Proposal for supporting new Java 8 date/time types

[Christian Kaltepoth]

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 at 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 at 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 at hibernate.org>:
>>
>> Anyone with thoughts/input on supporting the JSR 310 types?
>>
>> 2016-08-25 12:10 GMT+02:00 Gunnar Morling <gunnar at 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 at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>>
>>
>>
>> _______________________________________________
>> beanvalidation-dev mailing list
>> beanvalidation-dev at 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 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20160906/94cf1fbc/attachment-0001.html