Coding video material means that you cannot be more accurate than the number of frames per second of your video allow for.
oAt 25 fps, a single frame has a duration of 40 milliseconds (1000:25).
oAt 29.97 fps, a single frame has a duration of 33.3667 milliseconds (1000:29.97)
INTERACT stores all start time and offset time information as a 100Nanosecond value. How your data is displayed, depends on the format you selected.
While coding, INTERACT tries to log all time values at rounded millisecond values that match the length of a single frame at the current fps.
Coding videos at 29.97, 30 or 60 fps (or any other value that does not result in a full millisecond value for its duration per frame) will always create some tiny rounding issues at some point, due to pure math.
You can easily check the accuracy if you select the hh:mm:ss.xxx time format in the program settings. The chosen format is just for displaying the data; it does NOT alter the available time information.
If the milliseconds values do not show a matching rhythm, some internal latencies might have prevented a proper rounding or the fps value has been manipulated after logging.
Noticeable Discrepancies
You my experience discrepancies in timing in the following situations:
oDuration of a single Event - Presume you have logged an exact 2 second Event like this 00:00:00:00 - 00:00:01:29.
Changing the document fps to 25 will result in a different frame numer, but other than that, all is well:
Still it causes a tiny glitch in for instance the State-Space-Grid, because of the difference on millisecond level:
Fix Discrepancies
If your data was logged at 29.97 fps and you change the document fps value to 25 fps, the available time information will not exactly fit these frames.
That is why INTERACT offers the command Transform - Time Values - Shift 
.
Running this command will adjust all original time information, stored in the data file, to match the current fps value as good as possible:
