I'm not sure this counts as a constructive comment, but an interesting anecdote anyway - an early coding partner of mine once wrote a procedure he expected to run once exactly every second by continuously polling the time in a while/do_nothing loop until exactly one second had passed. It took some convincing to get him to accept that try as he might, it was very unlikely that "==" was what he wanted there.
The best part was that this was in Javascript (and obviously he was not using a timeout). The entire page would lock up while it waited for the second to elapse. He never even figured out the obvious usability concern because he was so confounded by the fact that the procedure wasn't getting called after a second had passed.
Ok, to be fair, it was a freshman year programming class - not an unexpected or even unusual mistake. But it gave me a chuckle just now remembering it.
Somewhat related, but I've seen a lot of retry-with-a-timeout loops that will either throw a spurious timeout error or wait for a very long time if the system clock just happens to jump at the right time.
Another amusing anecdote: I got an old PowerBook out of storage and booted it up. The battery had run flat, so the clock reset to 1970. Spotlight noticed this and decided it had to reindex the entire drive. At some point during all of this, NTP kicked in and reset the clock to the correct year. I wanted to see how long Spotlight would take to finish indexing, so I popped down the menu. The progress bar indicated that it was about halfway done, and based on how long it had taken so far, it estimated that only another 40 years would be required to finish!
40. You can wait for the clock to reach exactly HH:MM:SS by sampling once a second.