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

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

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.

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.

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

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.