The Timer register continues to increment after the interrupt time. If you code like in the tutorial then the timer stops incrementing at the time the timer is disabled before reloading with the new re-load value.
Then when it is re-enabled it will start to increment again.

The author of the tutorial describes in his additional notes section at the end that it may be necessary to compensate the reload value for the timer according to the length of time the timer is disabled. HOWEVER THE AUTHOR HAS NEGLECTED THE ISSUE THAT THE TIMER MAY HAVE ACCUMULATED SOME COUNT BY THE TIME THE SOFTWARE GETS AROUND TO PROGRAMMING THE NEW RELOAD VALUE. If you intend to make an RTC using a 8051 timer 1 or timer 0 then you should also take into account this additional issue. One way to do this is to read the timer counter value and the reload the timer with the value of:

TIMER_RESET = TIMER_RELOAD - TIMER_DISABLE_TIME - TIMER_OVERRUN

...where the TIMER_OVERRUN value is the value read from the timer after it was disabled and TIMER_DISABLE_TIME is the total number of instruction cycles involved time through which the timer is disabled (5 cycles in the tutorial example, but more in a real example where the timer must be read and subtracted from the fixed reload constant).

A easier scheme to deal with timer interrupts for an RTC is through use of a different type of timer mechansism. Some 8052 derivatives have a timer setup called the PCA. The PCA is based upon a 16 bit timer that runs in a continuous free running manner. It is then possible to configure a PCA channel to generate a timer interrupt on an "output compare" function. In this scheme you program the output compare register with a future value of the free running counter upon which time you would like an interrupt to occur. In the case of an RTC this value is maybe set to be 1/10 or 1/20th second from the current time. A cool thing is that in the case of RTC application the new output compare value programmed each interrupt time can be programmed simply as the old output compare value plus the 1/20th second offset value. The amount the free running counter has advanced past the previous output compare value is simply accumulated into the time when the new output compare value will generate the next interrupt. Of course according to Edsyl Murphy you never get anything for free, so in the case of PCA timers the trade off that exists is that the new output compare value that you re-load needs to be a value at least greater than the worst case run-beyond value that is in the PCA free running counter.

Hope this hepls.
Michael Karas