On Mon, Oct 10, 2016 at 12:38 PM, Hardy Ferentschik <hardy(a)hibernate.org>
> > 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?
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
> > 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
> 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
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
I think people tend to use LocaDate and implicitly think they apply
their time zone.
If nothing else, the specification and the documentation of would
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
> > 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
> a system is only used in a single location), that's what should be used
> 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
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
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) ;-)