> On the server side the time might get parsed preserving the zone, but then in the constraint validator OffsetTime.now( ) is called using the servers time zone. IMO it is the best to take a potential timezone into consideration. @gunnarmorling, WDYT? 

Unless I'm missing something, both the passed object from the client and the `OffsetDateTime.now()` in the validator have offset and zone data, so the API is able to convert both to a point in the timeline and compare them. Similarly with different calendars, the API allows direct comparison between ISO and Hijrah and Japanese calendars...etc.

I tested `OffsetDateTime` and `ChronoZonedDateTime` using all of the allowed offsets (-18 to 18) with 1 hour difference between future and past, and the tests passed.

> I don't think these are edge cases.

True :)