On Mon, Oct 10, 2016 at 10:12 AM, Hardy Ferentschik <hardy@hibernate.org> wrote:

So what would be the difference to the TimeProvider which is currently supported as a Hibernate Validator specific
extension. Very similar, right?

Could you please send the link to me, please?

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).

It is. If there is ever more than one TZ, you shouldn't be using LocalDate. We cannot encourage people to use the wrong type for the job.

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.

This shows a misunderstanding of choosing the type you need. If you have LDT, you have a single fixed time zone that you know what is (for instance, a system is only used in a single location), that's what should be used in the server side for comparison. If you have different time zones, you probably need ZDT.

Regards,

Michael