Just in case you find no better way, you can always just wait the right amount of time and then set the time in seconds.
This seems like the most likely way to get this to work, but there are definitely pitfalls.
Just as an example, say the time you get from your source (assuming you have a source that can reliably give you centisecond precision, much less millisecond precision) of 17:54:23.11. So logically you want to wait .89 seconds, then set the time to 17:54:24. So how would we wait for .89 seconds?
There's no easy way I know of in standard C, but say our system provides sleep(), usleep(), or even nanosleep() with second, microsecond, and nanosecond resolution. Well, sleep() is out of the question, not precise enough. So what about usleep(), it should be fine, 89 centiseconds is 890000 microseconds, so we should be able to usleep that long, then set the time, right? Sadly, not really. From the usleep man page:
The usleep() function suspends execution of the calling thread until
either microseconds microseconds have elapsed or a signal is delivered to
the thread and its action is to invoke a signal-catching function or to
terminate the thread or process. The actual time slept may be longer,
due to system latencies and possible limitations in the timer resolution
of the hardware.
So we know that AT LEAST 890000 microseconds have elapsed. Or maybe it was 1000000 microseconds. We just know it was no less than 890000. Hm. That's less than ideal. This then breaks down to trying to usleep() in 100 microsecond intervals or so, and checking the time with localtime() or something similar. Of course, just doing those actions takes a non-zero amount of time, so you're never really going to be sure. I suppose with this method you could get closer than trying to sleep the exact amount of time, but you're unlikely to get within a centisecond much less a millisecond.
I guess if I had to try to get this as close as possible, i'd get the localtime() right when I got the "real" time from the external source, and see how many microseconds away from the next "real" second I was. I'd then just busyloop localtime() and difftime() until I was within about 5 milliseconds to 1 centisecond of the "real" date to the second and then call date to hope that it takes about that much time for the set to actually take affect. You'd just have to hope for the best in terms of the CPU interrupting your program between finding you're within 5 milliseconds and you setting the date. You could get another reading from your "real" date source and compare it to localtime afterwards to ensure you got within an acceptable threshold, and if not try again.
I wouldn't normally recommend busylooping ever, but in this case it would be for at most 1 second, and sleep failing to give any guarantee of return near the time you specify forces your hand.
-Lee
