So that I understand the question: Do you mean “time dilation” in the sense of “slowly drift the clock until you are at the desired offset?”

Or, put another way: What is the other option you're comparing against?

Yes, you need the client to run its local command inputs ahead of the server.

Yes, the server needs to tell you whether you're late or early.

When you find that you're too early, you can slow down the local clock until you're caught up, or you can immediately delay by a tick or two, causing a “jump.” If by “time dilation” mean you “run the clock slower by 5%,” then that's a reasonable choice for the case when you're ahead of where you need to be, as it will create a less jarring hitch than a simple “delay for N frames.”

When you find that you're too late, you need to catch up much quicker, because you will be sending commands that won't take effect because they're too late. Time dilation will just prolong how long it takes before you're in synch, so to catch up, you should immediately step all the necessary steps to get to the target time delay, to reduce player discrepancy. At least, once you're actually behind (not just later than desired, but actually missing the step,) immediately catch up.

So, let's say that you aim for the player to be 2 steps ahead on average. If it's between 1.5 and 3.0 steps ahead, run at regular clock. If it's more than 3.0 steps ahead, slow down clock by 5%. If it's between 0 and 1.5 steps ahead, speed up by 5%. And if it's below 0 steps ahead, immediately step forward by 2.0 + time-behind steps.