Re: [bv-dev] Proposal for supporting new Java 8 date/time types
On Tue, Oct 11, 2016 at 9:46 AM, Hardy Ferentschik <hardy(a)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
Attachments:
- attachment.html (text/html — 2.3 KB)