[bv-dev] Improved java.time support follow-up

[Guillaume Smet]

Hi and happy new year to everyone!

We discussed a couple of things today with Gunnar and we have a couple of
questions for you all regarding the improved java.time support we committed
before the holidays.

1. Support for partials
================

The initial proposal of Michael included the support for partials such as
YearMonth or MonthDay (ie types which do not strictly represent a point in
time).

While @Past and @Future make sense for YearMonth, it's a bit more difficult
to define them for MonthDay.

The implementation we committed indeed supports MonthDay by building a
MonthDay from the Clock provided by the ClockProvider and comparing them
using MonthDay.compare(...).

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

Partials currently supported are:
- LocalTime
- MonthDay
- OffsetTime
- Year
- YearMonth

I think Year and YearMonth can be considered OK without further discussion.
LocalTime and OffsetTime, I can think of use cases. MonthDay, well, I
didn't find any potential use case and it looks just weird.

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

So, any thoughts on this? Use cases, votes for removing it/keeping it?

2. Resolution
==========

In the comments of https://hibernate.atlassian.net/browse/HV-820, someone
suggested the idea of resolution.

You could have something like:

@Future(resolution = ChronoUnit.MONTHS)
private LocalDate paymentDate;

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

It might also be useful to reduce the resolution of ZonedDateTimes to days
before doing the comparison, especially when using the orPresent option.

Note that it's only useful if you use a type more precise than what you
require for the validation so it might be a very narrow use case not worth
adding additional complexity to the standard constraints.

Do you see any use cases for that? Have you ever used custom constraints
for that?

3. orPresent
=========

The current implementation adds orPresent support as an option of the
preexisting @Past/@Future annotations:
@Past(orPresent = true) / @Future(orPresent = true)

Gunnar suggested this afternoon that it might be more readable to have
@PastOrPresent/@FutureOrPresent, especially if we have more than one
options for @Past/@Future.

Something like @Past(resolution = DAY, orPresent = true) would be less
readable than @PastOrPresent(resolution = DAY).

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.

Thoughts?

Thanks.

-- 
Guillaume
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20170105/3e9416b9/attachment.html