Years back, when iPhones took time from the phone company, it was not uncommon for AT&T to set time that was up to about two minutes off true time. My satellite tracking app, while not requiring high precision, needed better than that to avoid people hunting on the wrong side of the sky! I wrote a little SNTP library so my app didn't have to rely on clock time.
The [S]NTP process relies on, simplifiying, averaging resonses from multiple time-servers. It collects those server names from a pool address (pool.ntp.org, etc) which uses DNS round robin to make a random selection from a pool of time servers that have volunteered to be in the pool, for example:
% host pool.ntp.org
pool.ntp.org has address 173.255.215.209
pool.ntp.org has address 44.190.6.254
pool.ntp.org has address 74.6.168.73
pool.ntp.org has address 96.8.121.205
The client software then fires UDP queries at all the servers, filters out less reliable one and uses the rest averaging their responses in aggregate, and over time. I know, Quinn, that there's nothing new to you in this but I've laid it out for future readers.
Some people, and organizations, used my library to get a true time when naughty users were trying to defeat software expiration by setting their device clock back to an earlier date. My library is antiquated (written many years ago) and somewhat redundant (it's my experience that Apple's devices keep sub-second accurate time). Because of the age of my software, and the remaining ability to defeat expiry dates, I started to write an improved version in Swift using the Network framework and tripped over the topic of my original question.
I'm amused to re-read my Radar report related to this topic you suggested I submit in 2010 (FB6015112) .. today I'd add to to my CoreTime suggestion the ability to ask the OS for true time, regardless of any fiddling with the system clock setting! Happy Hogmanay ..