<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Oct 10, 2016 at 12:38 PM, Hardy Ferentschik <span dir="ltr"><<a href="mailto:hardy@hibernate.org" target="_blank">hardy@hibernate.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<span><br>
> > So what would be the difference to the TimeProvider which is currently<br>
> > supported as a Hibernate Validator specific<br>
> > extension. Very similar, right?<br>
><br>
><br>
> Could you please send the link to me, please?<br>
<br>
</span><a href="http://docs.jboss.org/hibernate/stable/validator/reference/en-US/html_single/#section-time-provider" rel="noreferrer" target="_blank">http://docs.jboss.org/hibernat<wbr>e/stable/validator/reference/<wbr>en-US/html_single/#section-<wbr>time-provider</a></blockquote><div><br></div><div>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).</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>
> > How does this solve so the problem of determining the time zone of say a<br>
> > LocalDate at time of validation.<br>
> > Say the LocalDate is generated on a client and send to a server where<br>
> > validation occurs. Any time zone from the client<br>
> > side is lost. Is the assumption in this proposition that the time zone of<br>
> > the server is used? I don't think this would<br>
> > be correct (at least not in all cases).<br>
> ><br>
><br>
> It is. If there is ever more than one TZ, you shouldn't be using LocalDate.<br>
> We cannot encourage people to use the wrong type for the job.<br>
<br>
</span>Ahh, that's interesting. I agree, if you assume that in the case of a LocalDate only one<br>
single time zone is used, then all is good. </blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">But that really introduces a difference in<br>
behavior between date types which are representing an instant in time and the ones which<br>
are not, right? In the former the time zone which is part of the date type itself is<br>
used for comparison which might differ from the time zone of the server where the validation<br>
occurs. In the latter, it is implicitly assumed that for comparison purposes the time<br>
zone of the server is used to establish 'now' and to set the missing time/date fields of<br>
the LocalDate.<br></blockquote><div><br></div><div>Yes.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I think people tend to use LocaDate and implicitly think they apply to their time zone.<br></blockquote><div><br></div><div>Yes.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
If nothing else, the specification and the documentation of would have to be very clear<br>
on the expected behaviour. </blockquote><div><br></div><div>In theory, Date & Time javadocs due that already :-)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Personally I am still inclined to say that it just does not<br>
make sense to define @Past and @Future at date types which don't define an instant in time.<br></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>
> > I guess a simple solution would be to define in the spec that date/time<br>
> > types which are not an instant in time will<br>
> > always use a fixed time zone (eg UTC) for comparison. This would most<br>
> > likely also lead to some confusing border cases<br>
> > for users, but it would be deterministic.<br>
> ><br>
><br>
> This shows a misunderstanding of choosing the type you need. If you have<br>
> LDT, you have a single fixed time zone that you know what is (for instance,<br>
> a system is only used in a single location), that's what should be used in<br>
> the server side for comparison. If you have different time zones, you<br>
> probably need ZDT.<br>
<br>
</span>Right. I fear though that people will/want to use LocalDate in global applications<br>
as well, to for example represent things like birthdays.</blockquote><div><br></div><div>For a birthday, you should use MonthDay :-)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> However as you say, the moment you are having an application where users </blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">reside in more than one time zone,<br>
one needs to use date types which are actual instants in time.<br></blockquote><div><br></div><div>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) ;-)</div><div><br></div><div>Regards,</div><div>Michael</div></div><br></div></div>