Set ATEM timecode to Windows PC time.

Small command line utility for Windows. You must be running ATEM v8 for this to work. I have only tested it on my TVS HD Pro.
https://ianmorrish.wordpress.com/2019/06/08/set-atem-timecode-to-pc-time/

I was working on a similar utility for Mac OS, but so far I'm a little disappointed in the time sync accuracy that is possible with this approach. Immediately after setting the ATEM timecode to the system clock, the timecode being generated from the ATEM is often off by half a second (sometimes close to a full second) or so.

When set to sync via network time (using NTP or similar mechanisms), the system clock of the computer is actually pretty accurate. Since it only takes a few milliseconds (less than a frame) to send a command to the ATEM over a local network, I was hoping that it would be possible to achieve close to frame level accuracy when jamming the ATEM's timecode generator to the system clock.

But this doesn't seem to be the case in tests I have done so far. What's strange, is that the offset seems to be variable. There doesn't seem to be a fixed delay in setting the ATEM timecode. Sometimes the offset is less (a few frames), sometimes more (close to a full second). Not sure if this is a limitation with the SDK or with the ATEM itself.

I have found the same thing with the Windows SDK. Although I can never get is closer than 1/2 second.
As this is a new feature, lets hope BMD will resolve or provide advice on how to make it accurate.

The new timecode functions don't seem to be mentioned at all in the latest SDK documentation. So even though they seem pretty straightforward, I suppose it's possible there is some trick to using them.

Since the ATEM control panel interface only lets you set hours, minutes, and seconds, I initially thought that maybe the frames parameter was ignored entirely. So I tried setting the timecode when the frame count would be 0 (when a change in seconds on the system clock happens), but this didn't seem to make a difference.

The other thing that is a bit odd, is that if you immediately call GetTimeCode() after calling SetTimecode(), the SDK seems to return the old timecode value. Which suggests that there may be some delay in setting the new timecode value.

I'm also not clear on what the purpose of the RequestTimeCode() function is. Does this need to be called before calling GetTimeCode()? Does it change what events are generated? It seems like at least some TimeCodeChanged events are generated without calling RequestTimeCode() though, so its purpose is a little murky.