Since we now know that our OP will ultimately be working with an AB PLC lets talk about that for a moment.
The AB TON instruction supports multiple time bases, depending on the platform. I'll choose Logix500 platforms for this discussion since they are so common, but the same principles apply to other platform.
Since my purpose is to illustrate some nuances that result from the timer actually being a computer instruction as opposed to a hardware timer, lets just pretend that our PLC's internal time reference is dead nuts on and leave that discussion tangent by the way side.
The logic in the OP can be carried out by a simple single timer in any AB PLC. I'll select a one second time base and a 10,000 second preset for the timer as those are supported in the SLC500.
For the sake of discussion, lets pretend that the logic above is part of a larger PLC program that takes 5 milliseconds, including the IO updates, to scan. The switch wired to input I:1/0 is closed at any arbitrary time and at the beginning of the next scan the input image table is updated to reflect that bit I:1/0 now has a value of 1. At some point in the program the timer instruction above will be exectued and it will begin recording the passage of time. This is not the passage of time from the instant the switch was closed, but from the time that the TON instruction was executed on memory address T4:0 after the switch was closed, which could be up to 5 milliseconds later.
Now lets leave our PLC undisturbed for 10,000 seconds. Remember we are pretending that our PLC time reference is exactly accurate for the sake of illustrating the point, but suffice it to say, that there will be a time where exactly 10,000 seconds have passed since the timer instruction addressed to T4:0 was first evaluated as enabled. Where will the PLC be in its program scan at that point in time? We don't know, it could be immediately before the TON instruction (best case) or immediately after the TON instruction (worst case), or anywhere else in the program scan. So our timer instruction could actually execute up to five milliseconds after the time period actually expired, meaning that it might be up to five milliseconds late on setting its done, DN, bit. This means our timing accuracy with respect to the switch closure could be 10,000 seconds plus 10 milliseconds. That is, it could be ten milliseconds late in writing a 1 into the DN bit.
The actual output switching on could be a few additonal milliseconds, up to an additional five milliseconds (depending on where in the program our TON instruction is located) + the actual swtich time of the hardware.
Now lets look at the AB equivalent of the OP program. A five second self resetting timer operates a counter to count 2000 five second periods.
Same scan conditons as above apply. The timer instruction will be executed at a time up to five milliseconds after the switch wired to I:1/0 is closed. At that point in time it will begin tracking a five second time period. Time marches on, and five seconds expires. The processor could be on any instruction in the PLC program. It could be on the instruction immediately before the TON instruction (best case) or immediately after (worst case). Once again, when the timer instruction is executed and the DN bit is set, it could be five milliseconds late. So when our counter's accumulator counts up to 1, that could mean that a time anywhere from 5.0 to 5.005 seconds has passed. So far, so good, we expected that. On to the next scan. Remember that the timer DN bit is set. Next time the rung with our TON instruction is scanned the rung is false because the DN bit is set, so the timer instruction resets the ACC value in the memory element T4:0, and clears the DN bit and enable bit. Then it moves on. And the next scan after that the rung is true so the processor begins recording the passage of time again. Did you catch that? Two scans passed. That's the passage of ten milliseconds of time that were not accounted for. After our counter reaches 2,000 counts we are going to be off by twenty seconds absolutely best case, and off by maybe 30 seconds worst case. At this point the milliseconds lost at switch closure and ouput hardware update times seem like tears in the ocean.
Now we have a 999.9 second time limitation in the OP program, how would one minimize the error of timing 10,000 seconds? The error almost seems to be unavoidable. One way is to minimize the number of times we add in the error icurred every time the timer times out. At five second intervals we have 2,000 opportunities to totalize timing errors. But at 100 second intervals we have 100 opportunities to totalize timing errors, and at 500 second intervals we have just twenty opportunities. There are other methods as well which are not difficult to implement and are more accurate, but thats beyond the scope of this particular post, but I've covered them in other threads if one is inclined to search.
BTW, sometimes we have a tendency to think that a .01 second time base will be more accurate at timing than a one second time base, but that is not the case. A ten second timer using a one second time base will be just as accurate as a ten second timer using a .01 second time base (refer to Ron's links on how timers work if you want to get into the reasons) however, a 1 second time base has a problem resolving a 9.5 second time period, and a .01 second timer has a problem timing past five and a half minutes.
