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

[Michael Nascimento]

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

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

Yes.


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

Yes.


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

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