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

Hi all, Finally circling back to this one, many thanks for all your comments! Sorry for the long delay, I was sidetracked with a conference and some other things. To those asking about support for Period or Duration, how would that look like exactly? I reckon we'd need some new constraints along the lines of @MinDuration(value=6000, unit=SECOND)? What would be a use case for validating durations like this? I can somehow see it, but it seems rather specialized to me. 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. It's a good point. I'd dislike adding a parameter object without any properties, "just in case", though. But this is a case where Java 8 default methods are helpful: Should we ever see the need for some context parameter in a subsequent revision, we can add a new method for this and let it delegate to the parameterless one by default. type is not so widely used, but it feels strange to not support it if we support "Year". Yes, I think you are right. YearMonth and Year, should we perhaps enhance them to allow the user to specify that the "current" year/month/date should also be valid? That's a very good point, too! This one has been specifically brought up with https://hibernate.atlassian.net/browse/BVAL-466. It seems sensible to add an annotation parameter for this given the support for these non-instant types. When looking at your example, I'd have a hard time though to reason the exact semantics of inclusive(). I hope we could find something more descriptive? Btw. Michael (who has been part of the JSR 310 EG) pointed out that TimeProvider should return a Clock. --Gunnar 2016-09-06 6:53 GMT+02:00 Christian Kaltepoth <christian(a)kaltepoth.de&gt;: > 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* > type is not so widely used, but it feels strange to not support it if we > support "Year". > > > 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&gt;: > >> 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&gt; >> 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&gt;: >>> >>> Anyone with thoughts/input on supporting the JSR 310 types? >>> >>> 2016-08-25 12:10 GMT+02:00 Gunnar Morling <gunnar(a)hibernate.org&gt;: >>> >>>> 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 > > > _______________________________________________ > beanvalidation-dev mailing list > beanvalidation-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/beanvalidation-dev >