Also you can lower your clocks by 10%
I set all my clocks 15 minutes behind.. didn't help.. just got me to work late!
JK
Note on the "numbers"... You have to remember that "shares" have ID's... and a DIFF 1 share may come back solved after DIFF 1, or 2, or 30, or 458, or 1.4K.... Thus, it arrives "late"... sooo... initially it will be added to the count when it "arrives", in the "next block"... but when "calculated" hours later, it is sorted by ID#... thus, it moves back into the correct block below. So your adjustment is correct, sort-of... (It should be half and half, but that is a little more complex to process. Starting in block 222, but finishing in block 223, and in block 222 you had 0.000021% of the work-load, but in block 223 you had 0.000032% of the workload, so it looks like you lost a little as it moves back to where it should have been, in the lower share-stack.)
If the SHARE identified itself as the ID, in the "final results" or the "final results" were what was recorded for you to see... you would never notice it.
P.S. that is also how you get strange hash-rates... because you "are still solving" a share from the last-update... which comes back with a crazy-high number in the next update of your hash-rate. Like returning a DIFF 380/1... thus your prior hash calculation is short by 380, and the hash estimate now is +380 more than it should be, on the new hash-rate.
That plus network lag... delivering late packets. But TCP always delivers... so you ALWAYS get credit. It resends until it makes it home.
P.S. "Best share" should be correctly labeled "worst share"... It took LONGER, and thus, was "bad"... a "best", would be finding a 1/1 on every DIFF 1 share... not finding a DIFF 1 after 380 share-times (DIFF 380/1)