[bv-dev] Proposal for supporting new Java 8 date/time types

[Michael Nascimento]

On Tue, Oct 11, 2016 at 9:46 AM, Hardy Ferentschik <hardy at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20161011/02863ac0/attachment-0001.html