When I check the clock on my phone or laptop against my radio alarm or time.is, I usually see a time drift between a second or two. Now, this isn't really a problem when it comes to simply knowing the approximate time, but it gives me massive headaches when it comes to file syncing.<p>I have a server to which I constantly synchronize all of my important files as a read-only backup. Now, the issue is that when I make a change on device A, sync it to device B, make another change there, and then sync it to my server - then there is a reasonable chance that the timestamps of the two changes will either overlap or be in reverse order! This will, obviously, lead to data loss.<p>What boggles my mind is how easy this would be to fix! Windows already uses NTP to sync the system clock, but it seems to do this so rarely as to regularly accrue seconds of time drift. Why? NTP sync requires negligible amounts of system resources.<p>Even worse is my phone. It can obviously receive GPS signals for geolocation, and therefore has access to the most accurate time signal available. But it doesn't even use it! When my phone is disconnected from any network, it will simply get less and less accurate while throwing away a constant stream of atomic timestamps from the GPS antenna. And while it is connected to the network, it suffers from the same weird reluctance to sync itself to time servers as often as possible.<p>Genuinely, am I missing something? My old 30$ Casio radio watch has more accurate time than all the very much more sophisticated and expensive tech around me. Why?
Quartz oscillators are sensitive to temperature. Modern computing involves varying power frequently, and therefore heat and temperature, so the real time clock varies a lot; even if we assume it sometimes gets calibrated / disciplined.<p>I think most phones sync to the cellular network time, when available. GPS would allow for an alternate time source, but it's not always enabled and maybe nobody thought to feed it into the time source while the network isn't available.<p>On Windows, I think the default settings for time sync are amazingly low; probably Microsoft didn't want to foot the bill, as they do run the servers windows syncs from, it's a <i>large</i> population, so increasing the sync volume would probably be meaningful. Microsoft also used to run a time server in Washington state somewhere with really bad asymmetric delay, leading to pretty poor sync performance. But it looks ok now.
I experience time drift with devices not connected to NTP like cheap stopwatch/microwave clock/etc, but my all my devices connected to NTP stay synced on their own.<p>For example:<p>- Windows time settings says: "Last successful time synchronization: 3/7/2024..." (This was ~41 hours ago and not manually triggered.)<p>- <a href="https://time.is/" rel="nofollow">https://time.is/</a>: "Your clock is 0.4 seconds ahead."<p>I'm a little surprised there is a 0.4 second difference, but it doesn't seem to affect syncing via Dropbox/Google files.<p>Perhaps the answer is that time that is accurate to within a second or so of precision is good enough for most consumers.
Have you explicitly told your phone etc to ignore sync or to use network time? My consumer stuff all works fine (Android and macOS), so I don't that think your sweeping claim in the headline is true. You may have simply gave a few troublesome devices with bugs or inappropriate settings/overrides.<p>(Yes, I care - I have run NTP servers including some of the first in banking - since long before it was fashionable, and some of my code is probably still in ntpd.)
This sounds more like a syncing strategy issue. Maybe you just need to schedule delays into the sync. Or more likely, stop peer syncing. Instead of syncing from A to B then B to server, sync A to sever then server to B. A master sync strategy that uses the time on master is probably better then peer syncing strategies if you're having issues with time keeping between systems.
This doesn't agree with my experience. If the time were consistently off by multiple seconds then the sweep second hand on my apple watch would stutter whenever the time was re-synchronized, but it does not.
Big picture - decades of cheaper-is-<i>always</i>-better design and BoM optimizations, and the perception that nobody cares about second-scale accuracy.