Support constraints on date/time types

[making]

Derived from #22 (comment)

[making]

If the expected feature is validating if the given value is in a range, I would provide constraints on Comparable rather than constraints on date/time types as supporting date/time is a bit tough (so many classes to support).

[making]

any comments would be appreciated

[night-crawler]

I would provide constraints on Comparable rather than constraints on date/time types

I'm just curious, will it help to supersede Number-alike constraint implementations, like BigIntegerConstraint, and other <Number>Constraint?

[making]

Good point. It could replace existing constraints. I need investigations.

[making]

I just noticed that most classes in JSR-310 did not implement Comparable.
I'll leave this issue open but this feature will not be included in 0.3.

[making]

I just noticed that most classes in JSR-310 did not implement Comparable.

This is not true. But it is not as simple as expected since LocalDateTime implements ChronoLocalDateTime<LocalDate> which extends Comparable<ChronoLocalDateTime<?>>.

[ffroliva]

I think that adding validation to LocalDate and LocalDateTime to cover before, after and between dates would be a good starting point. More complex scenarios could come later or even could be implemented with a custom validation.

[DiegoKrupitza]

I think that adding validation to LocalDate and LocalDateTime to cover before, after and between dates would be a good starting point. More complex scenarios could come later or even could be implemented with a custom validation.

I am right now working on this feature. The current approach is to have the following:

The base classes will implement common logic. It is basically has the same hierarchy as java.time (see here)

[DiegoKrupitza]

Update: I introduced a second layer so comparable temporals do not have to implement the same methods over and over again.

[ffroliva]

My understanding is that you need a extra field which your before and after method would use to compare against. How are you doind that?

…

On Mon, 27 Dec 2021, 20:42 Diego Krupitza, ***@***.***> wrote: Update: I introduced a second layer so comparable temporals do not have to implement the same methods over and over again. [image: TemporalConstraintsJAVI] <https://user-images.githubusercontent.com/25965672/147505921-1b33007e-ed9e-4739-a26a-51c42dcfaa5d.png> — Reply to this email directly, view it on GitHub <#37 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AF67VG7VYIHTM2U2BUKI5KDUTDFUVANCNFSM4KGUJDVA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you commented.Message ID: ***@***.***>

[DiegoKrupitza]

My understanding is that you need a extra field which your before and after method would use to compare against. How are you doind that?
…
On Mon, 27 Dec 2021, 20:42 Diego Krupitza, @.> wrote: Update: I introduced a second layer so comparable temporals do not have to implement the same methods over and over again. [image: TemporalConstraintsJAVI] https://user-images.githubusercontent.com/25965672/147505921-1b33007e-ed9e-4739-a26a-51c42dcfaa5d.png — Reply to this email directly, view it on GitHub <#37 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AF67VG7VYIHTM2U2BUKI5KDUTDFUVANCNFSM4KGUJDVA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub. You are receiving this because you commented.Message ID: @.>

The before and after method does include a parameter which is checked on. Further details can be seen in #195