Let's also assume that at update 00 below (i.e. For computational sake, but also to show what happens if the delay is near 0 when the system is idle, let's also suppose that the delay of Rainmeter is constant and has a value of 0 ms (none of those assumptions are true in a dynamic computer environment, of course, but it just makes illustrating the outcome easier, without affecting the conclusion you can have a different delay or a variable / dynamic delay as it actually happens, the only thing below that will be different will be the numbers, as the conclusion will remain the same, especially on significant delay variations).
To illustrate what happens, let's suppose we set a 900 ms update in the skin to try to be precise and eliminate the delays. Yeah, the thing is that no matter how one approaches this, there are going to be those "delays" that one cannot estimate precisely, and one just cannot do a perfectly accurate time skin in Rainmeter, simple because of how Rainmeter operates in the first place. I have not asked if this is wrong before so - I may be after all.
There is some delay between rainmeter and windows, the Time function is based on windows time, so shortening the delay will have no effect other than reducing if not eliminating any delays. I might sound like a 'rule breaker', but for clock skins, I have found Update=900 to be most effective in the clock keeping up with the windows clock.