6:04 a.m.
I'm not a big fan of this option.
I mean, who can we define the present?
On the same API that will easy:
- YearMonth
<https://docs.oracle.com/javase/8/docs/api/java/time/YearMonth.html>
- Year <https://docs.oracle.com/javase/8/docs/api/java/time/Year.html>
- LocalDate
<https://docs.oracle.com/javase/8/docs/api/java/time/LocalDate.html>
But the API that cares about milliseconds? that will complicate, so we need
to define a delta.
- LocalDateTime
<https://docs.oracle.com/javase/8/docs/api/java/time/LocalDateTime.html>
- LocalTime
<https://docs.oracle.com/javase/8/docs/api/java/time/LocalTime.html>
- Instant
<https://docs.oracle.com/javase/8/docs/api/java/time/Instant.html>
On Thu, Jun 22, 2017 at 4:15 AM, Marco Molteni <moltenma(a)gmail.com> wrote:
as they are a bit shorter to use and, more importantly, better to
> read.
I agree.
It's late in the game, but I feel inclined to extract @PastOrPresent
> and @FutureOrPresent. What do you think?
Ok for me.
On Wed, Jun 21, 2017 at 7:33 PM, Gunnar Morling <gunnar(a)hibernate.org>
wrote:
> Just from - very quickly - thinking, no options are coming to my mind.
>
> Note that we're about to push the Proposed Final Draft (CR1) with the
> separate annotations in a bit. We still an re-consider until the Final
> if something strongly speaks against it, but it seemed like the more
> likely option to me and the PFD should be out today so it's up online
> by the end of the week.
>
> I wish the question would have come up earlier so it wouldn't be such
> a rush, but well...
>
>
> 2017-06-21 19:00 GMT+02:00 Emmanuel Bernard <emmanuel(a)hibernate.org>:
> > My argument against is that @Past / @Future could need additional
> options: like maybe past per year or month instead of instant time. I
> understand we do use the type structure to extract that information.
> > Is there potential options people can think of around time constraints?
> >
> > For @Positive/@Negative, we decided there were none.
> >
> >> On 21 Jun 2017, at 11:50, Gunnar Morling <gunnar(a)hibernate.org>
wrote:
> >>
> >> Hi all,
> >>
> >> A colleague of mine reviewing the BV 2.0 changes pointed out an
> >> inconsistency in the added/modified constraints.
> >>
> >> As per the community poll we have now @NegativeOrZero and
> >> @PositiveOrZero, whereas we still have the orPresent() option on @Past
> >> and @Future. Should it be @PastOrPresent and @FutureOrPresent instead
> >> for the sake of consistency?
> >>
> >> Now one could argue that having only attributes (orPresent(),
> >> orZero()) is most consistent with other constraints such as
> >> @DigitalMin. But indeed the explicit annotations grew on me over time
> >> as they are a bit shorter to use and, more importantly, better to
> >> read.
> >>
> >> It's late in the game, but I feel inclined to extract @PastOrPresent
> >> and @FutureOrPresent. What do you think?
> >>
> >> Thanks,
> >>
> >> --Gunnar
> >> _______________________________________________
> >> 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
> _______________________________________________
> 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>*