I built a local competitive programming judge a while back where I fell into the exact trap of manually correlating steady_clock and system_clock.

I was timestamping everything using steady_clock to strictly enforce the time limits, and then just applied a calculated offset to convert that to wall time for the "Submission Date" display. It worked in testing, but during a long stress-test session, my laptop did an NTP sync. The logs then showed submissions appearing to happen before the source code file was last modified, which confused the caching logic. I was essentially betting that system_clock was stable relative to steady_clock over the process lifetime.

I eventually refactored to exactly what the article suggests: use steady_clock strictly for the runtime enforcement (is duration < 2.0s?), but capture system_clock::now() explicitly at the submission boundary for the logs, rather than trying to do math on the steady timestamp.

Also, +1 for std::chrono::round in C++20. I’ve seen code where duration_cast was used to "round" execution times to milliseconds for display, but it was silently flooring them. In a competitive programming context, reporting 1000ms when the actual time was 1000.9ms is a misleading difference because the latter gets Time Limit Exceeded error. Explicit rounding makes the intent much clearer.