Thanks a lot for your feedback!

On 1., I was initially a bit skeptical about @Future for partial types such as LocalTime or MonthDay, which don't denote "one point in time" but a recurring one. But after playing a bit with those types in the RI, having support for them felt alright.

On 2., agreed. People can always put their constraint to a derived member with the right resolution as pointed out by Michael, so I don't think it warrants explicit support.

On 3., ok, works for me.

Based on this feedback and the original proposal [1]. I've sent a pull request for updating the spec (https://github.com/beanvalidation/beanvalidation-spec/pull/122). Note that you need to take a look at the API project, too, in order to get the full picture (as we include API types directly from there). 

Any comments on this change are welcome. I'll leave the PR open until the end of the week end then merge it if nothing more comes up.

This change does not include support for range data types, I've opened BVAL-553 [2] for that one. @Michael, maybe you are up for writing a proposal for that one, too?

Thanks,

--Gunnar

[1] http://beanvalidation.org/proposals/BVAL-496/
[2] https://hibernate.atlassian.net/browse/BVAL-553



2017-01-08 12:43 GMT+01:00 Christian Kaltepoth <christian@kaltepoth.de>:
Hey all,

see my thoughts inline..


1. Support for partials
================
 
[....]

We tried to think of a use case but couldn't think of any.

When you are using a calendar year for fiscal purposes (in Brazil, its January-December), you could use MonthDay to represent a point in time separately from the year. If a MonthDay represents a holiday, there might be other use cases related to the current year.

That being said, it does not cost us anything to have it for consistency.

Consistency for me is a good argument in itself. If we couldn't think of the use case, maybe it's just because we're temporarily blind. Being consistent doesn't hurt, especially given the effort is minimum :-)

I agree with Michael. I could imagine use cases especially in the context of financials (just think of a fiscal year for example). So I would prefer to be consistent and just support it.

 
2. Resolution
==========
[...]

This would truncate the LocalDates to ChronoUnit.MONTHS before doing the comparison, ensuring that the date should be at least next month.


While this is a valid use case, it seems a little bit specific to me in the sense you have a reference for "now" as a comparison (a use case I mentioned before is validating a temporal object against an arbitrary reference) and in this case converting it. This also limits the "truncation" (which is just a specific case of conversion) to ChronoUnit, when other types of conversion might be needed.

I don't think this is a very common use case. So I currently don't see a good reason to support it. But may be I'm missing a common use case here?

 
 
3. orPresent
=========
[...]

Personally, I prefer having one annotation with an option rather than 2 different annotations - I think it has a better semantic - but I can see the rationale behind Gunnar's proposal.

I vote for one annotation.

I would also prefer one annotation. I think even something like @Past(resolution = DAY, orPresent = true) is quite good readable.


Christian


--
Christian Kaltepoth


_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev