On Tue, Oct 11, 2016 at 9:46 AM, Hardy Ferentschik <hardy@hibernate.org> wrote:

> > > 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.
> >
> > Ahh, that's interesting. I agree, if you assume that in the case of a
> > LocalDate only one
> > single time zone is used, then all is good.
>
>
> Not an assumption, design :-) A LocalDate means a date for which a single
> *implicit* timezone is used, the one at the Clock. It's the idea of having
> a wall clock in your room. Whatever date or time is shown there, you know
> which timezone to apply.

As you mention later on, there are so many bitfalls when dealing with timezones,
adding support for non instant based date/time types in BV will imo just add
yet another potential error source.

Not really. LocalDate should only be used for when there is a single, known timezone - and that's why in this situation there is zero confusion. If you use LocalDate when you shouldn't, you will have problems *everywhere*, with different JSRs, frameworks etc.

LocalDate should be a very common use case because the application:

- Is for a company with a single business unit or in which all of them are located in one timezone;

- Only runs in one country with one timezone;

- Runs server-side only and it uses its timezone for making decisions;

- Runs on a cell phone, for which all things should be based on the device

etc

All of these need decent support for LocalDate everywhere, including Bean Validation.

Regards,

Michael