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

[Hardy Ferentschik]

Hi,

> > http://docs.jboss.org/hibernate/stable/validator/reference/
> > en-US/html_single/#section-time-provider
> 
> 
> A Clock is the Date & Time API way of saying date-time point (scientific
> scale) and time-zone info (human scale) to use. So, the second part is
> missing in the current TimeProvider (the first has less precise support in
> HV, since Instant is nano-second based).

Sure, fair enough. I just pointed this out for completeness 

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

> > If nothing else, the specification and the documentation of would have to
> > be very clear
> > on the expected behaviour.
> 
> 
> In theory, Date & Time javadocs due that already :-)

In theory.

> Most applications should be using local types because they are not used in
> more than one timezone, so it would really hurt the most common case. It's
> like doing a contained application vs a distributed one - you should only
> pay the distributed costs if needed.

Hmm, not sure about this. When I am thinking application, I most of the time
think web applications and there timezones do matter. I guess it comes down to
the domain in which you are writing applications.

> That's the easy part. The real hard part is thinking how timezones affect
> *everything* about your application, which is not simple at all. I could
> give examples of how that is not trivial (and most applications handle it
> wrong), but then it would be totally off-topic (and time consuming) ;-)

:-)

--Hardy

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 496 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20161011/0cd09eeb/attachment.bin