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

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

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

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

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.

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