Master sync / timecode generators like our Evertz 5601MSC use a GPS reference, so not only is the video reference spot on for frequency, the time code is extremely stable. Nevertheless, at any given moment there will be some amount of error between the (drop frame) time code versus real time. The solution to this is called “jam sync,” which essentially resets the time code, forcing it to match the real time once again. Some systems perform the jam when the error exceeds a set threshold; as you can imagine, this creates a fairly large jump and can be disruptive. Our equipment automatically performs the jam daily (ours takes place at 2am, when the automation doesn’t care). Not only does this correct for the relatively small mathematical imprecision you notice, it also makes provision for events like leap seconds that occur from time to time.
Naturally, this is only significant for operations that use time code to reflect real time — to control automation, or to index continuous recordings like air check systems. For time code within the context of specific program content, even shows that run several hours, uncorrected drop-frame code is accurate enough to run cleanly.
I’ve had to jam sync devices on a film set before, this is a way to be sure that all your equipment (cameras, audio, slate, etc.) have matching timecode. Since different internal timecode generators can drift slightly over time, you periodically re-sync everything to one master timecode generator. I didn’t know that similar equipment is used by broadcast engineers, but it makes sense. Another user, dcwar, pointed out that the manual for the Evertz Master Clock System that Jeff uses is available online. Page 54 has more detail about the jam sync process as well as a couple very cool graphs showing how drop-frame timecode can drift over the course of a day.
So there you have it, that’s why the very slight error in rounding frame rates to 29.97 doesn’t cause all television programming to slip by a few frames each day.