We use now - postBatchResumeTokenTs. The issue is that ts only has second granularity and we use the full ms value of now. This means that if the theoretical time for the resume token was 08:30.940 and time now is 80:30:950, the fetch delay will be reported as 950ms (950 - 0, 0 since ts has second granularity so it is rounded down) instead of the actual 10ms. This can artificially inflate the estimate and delay resharding from entering the critical section with the current default threshold of 500ms.

The apply estimate uses walltime that has ms precision, so it does not have the same issue (but at the mercy of clock skew).