Hi Gunnar, I agree with the implementation of @Past and @Future with the possibility to customize the TZ. 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). 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). Most of the uses cases that I see ask only the validation of a date (e.g. @Past date for an event, @Future date today for a payment) or (less frequently) date and time. Cheers On Tue, Aug 30, 2016 at 2:39 PM, Gunnar Morling <gunnar(a)hibernate.org&gt; wrote:

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: -- Otávio Gonçalves de Santana twitter: http://twitter.com/otaviojava site: *http://about.me/otaviojava <http://about.me/otaviojava>*

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 >

Hi, Michael mit with Stephen Colebourne during J1 this week and will write an updated proposal around the date/time support based on the current one and their discussions. Looking forward to it :) --Gunnar 2016-09-23 7:18 GMT+02:00 Christian Kaltepoth <christian(a)kaltepoth.de&gt;:

Hi guys, I was finally able to write something before taking my flight this morning. Let me know what you think: https://github.com/sjmisterm/beanvalidation.org/blob/760cd54cb1f00bac1ae8... Regards, Michael On Fri, Sep 23, 2016 at 4:04 AM, John Hendrikx <hjohn(a)xs4all.nl&gt; wrote:

Awesome, many thanks Michael! Going to look into the proposal asap. --Gunnar 2016-09-23 22:08 GMT+02:00 Michael Nascimento <misterm(a)gmail.com&gt;:

On Mon, Sep 26, 2016 at 5:18 AM, Gunnar Morling <gunnar(a)hibernate.org&gt; wrote: Nice! Unfortunately, it's not in any interface though. So we have to stick to what the interfaces provide... :-) All those sections without content are still to be written. In this case, according to the spec, there is no way to write a PastTemporalAccessorComparableConstraintValidator extends ConstraintValidator<Past, ? extends TemporalAccessor & Comparable<?>> or something like it, which is the natural choice. Making it just "extends ConstraintValidator<TemporalAccessor>" won't make it fail at the right phase if @Past is applied to a non-Comparable TemporalAccessor. I have a few ideas on how to address that, but maybe now you can get thinking too :-) These are TemporalAmount(s) with a single unit. For these, @Max and @Min support should work for the single unit they support. Sure, did I remove that? :-) Your call :-) I was just trying to consolidate everything about JSR-310 in a single proposal; there's nothing wrong with splitting it. Regards, Michael

Hi, 2016-09-26 14:00 GMT+02:00 Michael Nascimento <misterm(a)gmail.com&gt;: Yes, we could say something about these methods explicitly, but using the Comparable contract definitely simplifies things. Ok, got you. That'd only be a problem though if you wanted to write a single validator implementation for all of them, right? I'm wondering whether one wouldn't use several more specific implementations anyways, given one needs to invoke a specific static now() method? Ah, seeing now that Duration and Period implement these. I don't think I like @Max/@Min for these as it's not clear what the unit of the expected value is. New constraints may be more useful here: public void save(@MaxDuration(value=60, unit=ChronoUnit.SECONDS) Duration d) { ... } No, I think it was not yet part of the proposal :) Ok, I'd say if think you can come up with something for this quickly, go for it. Otherwise let's keep it separately. It'd be nice to have a first cut of stuff we can take and provide support for in the RI. Thanks a lot for your effort, Michael, that's much appreciated! Regards,

BTW, have you (any of you, not just Gunnar) read the new question I've added at the end of the proposal? That's the main use case with JSR-310 and BV that will be missing. Regards, Michael On Wed, Sep 28, 2016 at 10:37 AM, Michael Nascimento <misterm(a)gmail.com&gt; wrote:

On Wed, Sep 28, 2016 at 11:10 AM, Gunnar Morling <gunnar(a)hibernate.org&gt; wrote: I think my team was using class-level constraints for that before :-( It is. It would be really nice to support this, probably for any pair of Comparables. What do you think? Regards, Michael

Hi Gunnar, A little bit time drained here. I have it all in my head, but the time to write it down is scarce.... Hopefully I'll follow on Tuesday or Wednesday. If you want to split it in two parts so we can do the rest later (Duration/Period/TemporalAmounts/Comparables) and publish what we have now, I'd be fine with it. Regards, Michael On Thu, Oct 6, 2016 at 6:32 AM, Gunnar Morling <gunnar(a)hibernate.org&gt; wrote:

Hi, So I started to work on a first implementation in the API, the TCK and in HV. It's a bit different from the latest draft of Michael but I think it should be a good base for our discussions. * Bean Validation API: https://github.com/beanvalidation/beanvalidation-api/pull/70 * Bean Validation TCK: https://github.com/beanvalidation/beanvalidation-tck/pull/77 * HV: https://github.com/hibernate/hibernate-validator/pull/576 Main differences are: * I didn't use introspection to build the now object from the Clock and get the compareTo method. It would save some code but I don't think it's a good idea. I agree that it limits the support to officially supported types but I like it better this way. AbstractJavaTimeValidator makes it easy to add support for other types if required; * I implemented all the default java.time types in this first round but I'll add optional support for threeten-extras as a proprietary extension in a followup-up patch if we decide to keep this approach; * I named the nowIsValid option orPresent leading to having something like @Past(orPresent = true) which does not look too bad. Comments welcome! -- Guillaume On Wed, Oct 19, 2016 at 11:24 AM, Gunnar Morling <gunnar(a)hibernate.org&gt; wrote:

Hi there, I finally found some time to look at some of the BV 2.0 proposals. On Fri, 23-Sep-2016 17:08, Michael Nascimento wrote: So what would be the difference to the TimeProvider which is currently supported as a Hibernate Validator specific extension. Very similar, right? I see how one can use it to use the suggested API to determine the time zone for the creation of the 'now' instance. How does this solve so the problem of determining the time zone of say a LocalDate at time of validation. Say the LocalDate is generated on a client and send to a server where validation occurs. Any time zone from the client side is lost. Is the assumption in this proposition that the time zone of the server is used? I don't think this would be correct (at least not in all cases). I guess a simple solution would be to define in the spec that date/time types which are not an instant in time will always use a fixed time zone (eg UTC) for comparison. This would most likely also lead to some confusing border cases for users, but it would be deterministic. --Hardy --Hardy

Hi, http://docs.jboss.org/hibernate/stable/validator/reference/en-US/html_sin... Ahh, that's interesting. I agree, if you assume that in the case of a LocalDate only one single time zone is used, then all is good. But that really introduces a difference in behavior between date types which are representing an instant in time and the ones which are not, right? In the former the time zone which is part of the date type itself is used for comparison which might differ from the time zone of the server where the validation occurs. In the latter, it is implicitly assumed that for comparison purposes the time zone of the server is used to establish 'now' and to set the missing time/date fields of the LocalDate. I think people tend to use LocaDate and implicitly think they apply to their time zone. If nothing else, the specification and the documentation of would have to be very clear on the expected behaviour. Personally I am still inclined to say that it just does not make sense to define @Past and @Future at date types which don't define an instant in time. Right. I fear though that people will/want to use LocalDate in global applications as well, to for example represent things like birthdays. However as you say, the moment you are having an application where users reside in more than one time zone, one needs to use date types which are actual instants in time. --Hardy

Hi, Sure, fair enough. I just pointed this out for completeness As you mention later on, there are so many bitfalls when dealing with timezones, adding support for non instant based date/time types in BV will imo just add yet another potential error source. In theory. Hmm, not sure about this. When I am thinking application, I most of the time think web applications and there timezones do matter. I guess it comes down to the domain in which you are writing applications. :-) --Hardy