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

Michael Nascimento misterm at gmail.com
Mon Oct 10 12:08:56 EDT 2016

On Mon, Oct 10, 2016 at 12:38 PM, Hardy Ferentschik <hardy at hibernate.org>

> Hi,
> > > So what would be the difference to the TimeProvider which is currently
> > > supported as a Hibernate Validator specific
> > > extension. Very similar, right?
> >
> >
> > Could you please send the link to me, please?
> 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).

> > How does this solve so the problem of determining the time zone of say a
> > > LocalDate at time of validation.
> > > Say the LocalDate is generated on a client and send to a server where
> > > validation occurs. Any time zone from the client
> > > side is lost. Is the assumption in this proposition that the time zone
> of
> > > the server is used? I don't think this would
> > > be correct (at least not in all cases).
> > >
> >
> > 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.

> But that really introduces a difference in
> behavior between date types which are representing an instant in time and
> the ones which
> are not, right? In the former the time zone which is part of the date type
> itself is
> used for comparison which might differ from the time zone of the server
> where the validation
> occurs. In the latter, it is implicitly assumed that for comparison
> purposes the time
> zone of the server is used to establish 'now' and to set the missing
> time/date fields of
> the LocalDate.


> I think people tend to use LocaDate and implicitly think they apply to
> their time zone.


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

> Personally I am still inclined to say that it just does not
> make sense to define @Past and @Future at date types which don't define an
> instant in time.

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.

> > > I guess a simple solution would be to define in the spec that date/time
> > > types which are not an instant in time will
> > > always use a fixed time zone (eg UTC) for comparison. This would most
> > > likely also lead to some confusing border cases
> > > for users, but it would be deterministic.
> > >
> >
> > This shows a misunderstanding of choosing the type you need. If you have
> > LDT, you have a single fixed time zone that you know what is (for
> instance,
> > a system is only used in a single location), that's what should be used
> in
> > the server side for comparison. If you have different time zones, you
> > probably need ZDT.
> Right. I fear though that people will/want to use LocalDate in global
> applications
> as well, to for example represent things like birthdays.

For a birthday, you should use MonthDay :-)

> However as you say, the moment you are having an application where users

reside in more than one time zone,
> one needs to use date types which are actual instants in time.

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20161010/8c636e93/attachment.html 

More information about the beanvalidation-dev mailing list