Professional broadcasts use something called "time code". Time Code Generators work along with a sync generator to make sure that every frame that a television truck creates gets created at precisely the same moment, and gets tagged with a unique and sequential timecode. The better ones sync with GPS or a modem to give precision time, the cheaper ones you have to manually set - usually with a cell call to the atomic clock. We embed that timecode signal into the ancillary data of each video frame, and produce a side-channel audio signal with the data embedded for devices that can't accurately read the timecode from within the video frames. We have to be incredibly accurate - as a video frame that is a fraction of a microsecond out of time can cause all sorts of issues. This used to be a huge deal in analog standard-def video - any frame that was out of time could cause the picture to shift horizontally or vertically (think of bad tracking on VHS tapes as a small example). Even sync was less accurate - sync was delivered through "black burst" which was literally just that - a burst of a black video signal, where you took the sync pulse and lined it up to ensure the timing of the frame was accurate or "close enough". Now with HD, we use tri-level sync which is way more accurate.
For the TL;DR crowd, in a production truck we can make precision measurements of time based on our sync and time code. The company that has created a good percentage of the official replay systems in the US - DVSport - has no access to our sync or time code. They also take our uncompressed frames and compress them into a video stream. They generate something loosely akin to our time code, but really it's just a reference point to where in the compressed stream you'd like to view.
Because of the inherent inaccuracies of how they time tag their compressed video and the inaccuracies of their internal clock itself, their time code - even when properly set - can "float". The longer you record, the more float you get - and it's not unusual to see minutes of float in a day. But if your internal source clock is inaccurate - and your math is trying to divide a second into the wrong number of frames - you get issues like this. You get severe time code float with 60fps vs 59.94fps alone, and that's BEFORE considering how accurate your reference clock is, and without any regard to how accurate your MPEG video encoder is. People are speculating that the software didn't know the video source was 59,94fps and was doing math based on 29.97fps or 30fps.
Even in the professional world we get tiny bits of "float", but ours is typically only a frame or two per day. We also issue what's called a "time code jam" - where we issue a uniform break in the time code stream to make sure every device is still synchronized to each other without falling too far behind actual time of day. These cheaper replay devices don't come anywhere near that level of accuracy.
Now imagine loosely time-tagging video into a compressed stream, and taking that wholly inaccurate time and reattaching it to video frames that are being uncompressed by an MPEG decoder on-the-fly. And now you can see how accurate relying on a replay system time overlay is. Prosumer video products like DVSport don't hold a candle to the timing standards we use in professional television production. Not that they can't - they just don't. More than likely because it's never become an issue up until now - or worked "well enough" for no one to notice. That is, until something as big as the outcome of a game relies on your kludge of a modestly-accurate timing reference.