<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Oct 10, 2016 at 10:12 AM, Hardy Ferentschik <span dir="ltr">&lt;<a href="mailto:hardy@hibernate.org" target="_blank">hardy@hibernate.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">So what would be the difference to the TimeProvider which is currently supported as a Hibernate Validator specific<br>
extension. Very similar, right? </blockquote><div><br></div><div>Could you please send the link to me, please?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">How does this solve so the problem of determining the time zone of say a LocalDate at time of validation.<br>
Say the LocalDate is generated on a client and send to a server where validation occurs. Any time zone from the client<br>
side is lost. Is the assumption in this proposition that the time zone of the server is used? I don&#39;t think this would<br>
be correct (at least not in all cases).<br></blockquote><div><br></div><div>It is. If there is ever more than one TZ, you shouldn&#39;t be using LocalDate. We cannot encourage people to use the wrong type for the job.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I guess a simple solution would be to define in the spec that date/time types which are not an instant in time will<br>
always use a fixed time zone (eg UTC) for comparison. This would most likely also lead to some confusing border cases<br>
for users, but it would be deterministic.<br></blockquote><div><br></div><div>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&#39;s what should be used in the server side for comparison. If you have different time zones, you probably need ZDT.</div><div><br></div><div>Regards,</div><div>Michael</div></div></div></div>