I’m executing some test cases for EHRBASE and it seems to work when sending a datetime in the future, but is that semantically valid? Should this case be validated and return an error?
I can’t find anything in the REST API spec about that case.
IMO the version_at_time is about what exists at a point in time, and it is not possible to say what would exist at a point in time in the future. For instance if I keep executing the same GET with the same version_at_time, until I reach that moment, and different versions were committed before and after each execution of the GET with the same version_at_time, the result will be different.
When calling the operation with version_at_time in the past, the result will always be the same at each point in time (varying the version_at_time), but the future is unknown
I would not validate it. Suppose the client always sends the current timestamp in that field, and the system time on the client is accidentally one second ahead of server’s time, and then you have an issue where you should not have one.
By definition, a ‘future timepoint’ is a moment at which we don’t know what versions may have been committed between now and that point. So the result has to be an error - it should be a precondition that the time is <= now.
@thomas.beale that was exactly what I was thinking, though we need to consider what @matijap said about the current time in client vs. server. Maybe some kind of tolerance could be in place, like not considering minutes for the “future date” check, I mean to consider less precision.
I would say if there is a difference between times in server vs. client of more than a couple of minutes, then something is badly configured.
Of course I’m considering dates are datetimes with timezone, so the TZ is not an issue.
