Yes, it’s true that by attempting to synchronize the clocks, i.e. compensate for network latency, you will get better average-case performance. The more stable the user’s connection (steady ping), the better the sync will be. In certain circumstances, where you are trying to minimize the impact of latency on gameplay, like in a FPS, or in a skill-based game where the skills have cooldown times that are near the same order of magnitude as ping times, this can be significant. But it remains true that sync better than worst-case round-trip ping cannot be counted on.
For the example at hand, a game round timer that is presumably at least a couple of minutes, I personally wouldn’t bother with the added complexity of a sync’d clock. Normally, you would display a round timer in whole seconds anyways, so rounding to the nearest second will cover typical internet latency, which is typically less than half a second (and if ping is high and spiky, no sync scheme is going to help anyways).
You’re using wait(1). This isn’t guaranteed to be 1.0 second, it’s only guaranteed to be >= 1.0 second. It could be 1 second or 1.03 or 1.1 second depending on how slow a machine is.
The post underneath has the second part of the solution:
.Changed activates on any property changed. :GetPropertyChangedSignal(‘Value’) will only activate when the specified property is changed. Use the latter in cases where you will be dealing with value objects.