It is somewhat difficult to keep time in sync in distributed systems. Picking a (lets say "now at the wall clock") time at the client (which could be a browser that we have no control over) and instantly sending it to the backend can easily cause constraint validation for Future/FutureOrPresent constraint violations in one or Past/PastOrPresent constraint violations in the other direction. It would be nice if it would be possible to specify a skewTolerance-Duration as optional parameter for time based constraints or as a global validator property/ or property of the clock provider.
What do you think about something like?
Yes, we have been contemplating this before but didn't get to it in the time frame of BV 2.0 (which just was finalized). I'd suggest you open an issue in the reference implementation (HV JIRA project) for exploring this feature there. The way we could do it for the time being would be a separate annotation, to be given next to one of the temporal constraints such as @Future.
A downside is that such separate annotation would apply to all the temporal constraints hosted by the annotated element, but I think that's acceptable as there hardly will be more than one (or if so, they should be fine with the same skew value).
In addition to a global flag, I think it's important to implement this on a per-annotation basis for two reasons:
There are use cases where developers will want more finer grained control. Consider a source of sensors, which produce values every 100ms, ignoring those provided out of order within a 10ms buffer might be important, whereas say other logic within the same system (that shares the same Validator instance) might determine anything within 1 minute or 10 minutes as close enough.
Defining the tolerance within the annotation properties is far more descriptive as it's close to the logic, whereas a global property is far removed from the logic.