hoakley July 26, 2025 Macs, Technology

A brief history of time synchronisation

Two centuries ago it was quite normal for adjacent towns to be running local times that differed by many minutes. Even after the railways came and forced synchronisation so their timetables could work, many adults were content to keep time by the occasional glance at the clock on a church or civic building. In the decade before the arrival of the Mac, one of the everyday duties of the police was to respond to requests for the time. Over the last 40 years we have come to expect our computers to keep very accurate time, something that’s particularly important in networking.

The year after the first Mac, when few computers were connected to local networks and the Internet was still in gestation, the Network Time Protocol (NTP) was introduced to enable synchronisation of computer clocks. A few third-party utilities started offering this ability, such as Vremya, Network Time and Mac-NTP, but most of us had to perform this manually.

NTPv3 1998

With the release of System 8.5 in October 1998, support for the use of Network Time Servers was added to the Date & Time Control Panel. Apple offered three servers around the world, at time.apple.com, time.asia.apple.com and time.euro.apple.com, to ensure that all Mac users should have reasonably low-latency access to an NTP service, and some opted for those offered by centres of excellence such as NIST.

During their Classic period and for some years later, Mac internal clocks relied on small batteries for power. As those had limited lifetimes, the user had to periodically open their Mac’s case to replace its battery. Flat batteries were a common problem causing the system clock to be reset and so create havoc, but network time services didn’t seem to help that much.

Mac OS X 2000-01

When Mac OS X was introduced, it continued built-in support for NTP and Apple’s time servers, and that was later updated to NTPv4 after it was released in 2010.

When you started your Mac up, system time was initially set to that of the internal clock. Provided its battery wasn’t flat, that should have been reasonably close to real time. The NTP service then tried to connect to the designated time server, and asked it for the time. If the result differed substantially from that of the internal clock, NTP should correct the clock. This might have occurred by means a series of small corrections over a period, or one larger change: NTP uses a sophisticated algorithm to determine that, and to allow for delays that occur with transmission over the Internet. Periodically thereafter ntpd checked the network time server, correcting the clock as it needed, to achieve an overall accuracy of around 0.1 second.

In addition to traditional command tool support, the usual interface to this remained the Date & Time pane in System Preferences, seen here in 2015.

`timed` 2017

Just before Christmas 2014, Apple propagated a patch for a security vulnerability in NTP, the first to be applied automatically. Otherwise, syncing the clocks of Macs appears to have continued unaltered until macOS 10.13 High Sierra in 2017, when it was replaced by a new and proprietary service timed, described thus:
timed maintains system clock accuracy by synchronizing the clock with reference clocks via technologies like NTP. Inputs are merged inside of timed, where it calculates uncertainty to facilitate scheduling proactive time jobs. timed is also aware of power/battery conditions.
This was apparently derived from the same daemon that had been syncing the clocks in iPhones since iOS 5.0 in 2011.

This is run as a LaunchDaemon, found at /System/Library/LaunchDaemons/com.apple.timed.plist. The time server used is set in /etc/ntp.conf, and is normally time.apple.com. timed relies on three property lists in a locked-down directory /var/db/timed/. These are:

com.apple.timed.plist containing its cached state, with values for TMLastNtpFetchAttempt, TMLastRtcTime, TMSystemTimeSet and more, and binary data for STF and TDTF;
Library/Preferences/com.apple.preferences.datetime.plist with a single key-value pair for timezoneset, which should be true;
Library/Preferences/com.apple.timed.plist with two key-value pairs for NtpUseServicePort and TMAutomaticTimeOnlyEnabled, both set to true.

In 2020, macOS 11.0 Big Sur brought two additions to support basic SNTP:

sntp is a simple NTP client claimed to be able to set or slew the system clock if it’s out of sync;
sntpd is a basic SNTP server daemon that can be launched through /System/Library/LaunchDaemons/com.apple.sntpd.plist, and stores header data in /var/sntpd/state.bin.

Neither appears to be run or used routinely in macOS, as it prefers to continue handling this through timed and the com.apple.timed subsystem. SNTP had been defined as a simpler and fully interoperable way of using NTP, and had been merged into NTPv4 in 2010.

Unless a Mac is one of the few that isn’t connected to the Internet, it should be set to check time and clocks by syncing with Apple’s Time Server over the network. Standard settings for doing that are now located in the Date & Time section of General settings.

Time and date are set automatically using time.apple.com as the source, and where possible the time zone is set automatically using the Mac’s current location.

For some, though, syncing using timed isn’t sufficiently accurate, and they resort to a third-party utility chronyd via ChronyControl, bringing this brief history back full circle.

References

NIST Physics Laboratory (2002) Configuring Apple Macintoshes to use NIST Time Servers
NTP, Wikipedia
timed in High Sierra
sntp in Big Sur and later

29Comments

Add yours

1

joethewalrus on July 26, 2025 at 8:59 am
Reply

This is interesting to me, particularly because at times I’ve noticed macOS virtual machines rapidly lose sync with real time when denied access to the internet. I didn’t know about timed, but I’m curious if it is doing something to make that problem either better or worse. Perhaps there are changes that it needs to run accurately in a VM. I might try to replicate the issue again and do some log checking later this week.

This is a tangent, but I wasn’t aware that police were once responsible for providing time. It makes sense. I understand that for part of the 20th Century before I was born, it was common in the USA to call the phone operator (Dial ‘0’) and ask the time. By the 1980s when I was becoming a young phone user, there was a service on many area codes, free in many locales, where phone customers could dial 767-xxxx and an automated system would answer and recite the time in ten second intervals. (POP-CORN, 767-2676 was a common pneumonic.) The system survived into the 21st Century, but eventually was decommissioned due to declined use. Not to hijack the conversation, but I’m curious if similar setups existed around the world. Howard? Enzo?

I’d love to know more about the iPhone implementation too, merely out of curiosity, plus now knowing that parts of it were ported back to the Mac. I was impressed with the versatility of early iPhones that they would sync their time from a cellular network in the absence of an internet connection, presumably using the same protocol that non-internet GSM phones used, or over wifi in the absence of cellular coverage, presumably to time.apple.com.

LikeLiked by 1 person
- 2
  
  hoakley on July 26, 2025 at 1:22 pm
  Reply
  
  Which VMs? Those running on Apple silicon Macs shouldn’t, I don’t think, but on Intel Macs that may be a limitation in their virtualiser.
  I don’t think this was ever an explicit duty of the police, but as they invariably had a watch that was set to accurate time, and many folk didn’t then, it was a common means by which they assisted the public, which was an explicit part of their duties. How times have changed!
  One of the differences with Apple’s timed scheme is that it can and does obtain time from several different sources, whereas traditional NTP-based systems required an NTP server, so wouldn’t be as useful with an iPhone.
  Howard.
  
  LikeLiked by 2 people
  - 3
    
    Tristan Hubsch on July 26, 2025 at 2:14 pm
    Reply
    
    “How times have changed!” — truer words…
    
    LikeLiked by 2 people
  - 4
    
    joethewalrus on July 26, 2025 at 10:07 pm
    Reply
    
    It happened in an Apple Silicon VM using Viable. As soon as I can (Tuesday or Wednesday, maybe) I’ll see about reproducing it.
    
    LikeLiked by 1 person
    - 5
      
      hoakley on July 27, 2025 at 12:43 pm
      
      Thank you.
      Howard.
      
      LikeLike
- 6
  
  Tristan Hubsch on July 26, 2025 at 2:12 pm
  Reply
  
  Yes, I can attest to automated telephone time-services existing elsewhere in the World, such as in my erstwhile homeland in the Balkans. Ah… ϸe goode olde times of teenagers idly calling the London automated time-service, to the parents’s consternation when they received the monthly bill… international calls used to be veeery costly. (And, was that “mnemonic → pneumonic” an autocorrect flight of fancy 😱?)
  
  LikeLiked by 2 people
  - 7
    
    joethewalrus on July 26, 2025 at 10:16 pm
    Reply
    
    🤣 Thanks for catching that. Autocorrect is a mndemonic invention!
    
    LikeLiked by 1 person
- 8
  
  David C. on July 30, 2025 at 2:23 pm
  Reply
  
  I don’t know what macOS does but based on reading Linux kernel sources and my understanding of how MS-DOS used to work, PC operating systems don’t rely on a hardware clock for timekeeping. The computer will read the hardware clock at bootup, but will otherwise configure a periodic clock interrupt. This interrupt’s handler will increment a count of “ticks”, which the OS uses to derive the actual time. The hardware clock will only be read if explicitly read by software (and will be written as a part of setting the clock, of course).
  
  If the operating system running in your VM is doing the same thing, that could easily lead to clock skew, because the virtualized timer interrupts will not be consistently periodic. I would hope that the VM’s virtualized clock hardware will always report the correct time (from the host operating system), but the guest OS would need some mechanism (device driver?) to keep its clock sync’ed to the (virtual) hardware clock or something like NTP to sync from an external source.
  
  LikeLiked by 1 person
9

jpholbrook on July 26, 2025 at 1:04 pm
Reply

Jeff Geerling has a recent blog and YouTube video about the limits of accurate time on MacOS. His main comment is that Macs don’t have a way to attach an accurate time source via a hardware GPIO pin. You can do that on a Raspberry Pi and get a local time source accurate to microseconds or even nano seconds.Geerling demonstrates attaching a GPS via USB and using ChronyControl to more accurate time. Interesting stuff. https://www.jeffgeerling.com/blog/2025/using-gps-most-accurate-time-possible-on-mac

LikeLiked by 1 person
- 10
  
  hoakley on July 26, 2025 at 1:29 pm
  Reply
  
  Thank you.
  Modern Macs don’t have such inputs, because they’re an open invitation to hackers.
  Howard.
  
  LikeLiked by 2 people
- 11
  
  Tristan Hubsch on July 26, 2025 at 2:44 pm
  Reply
  
  That linked article starts in a most telling way: “I’m deep in the rabbit hole of all things time and timing.” For my own part (and I’ll bet a whole shilling, at least a handful of “the rest of us”), what’s the rush about 0.22 femtoseconds (.22E-15s)? My Mac already does the things that it does at an about 3E9 times swifter pace than the idiot at the keyboard; timing that to a 1.5E6-times finer precision yet is beyond pointless to me. —and I definitely prefer the lack of this “open invitation to hackers.” Hopefully, the Real Pros who really need that 0.22 fs precision can fend off hackers, or at least keep them contained. (As a high-energy physicist, I’m glad the requisite 22E6 times finer still (1E-23s) time measurements in strong interactions are handled by my experimentalist colleagues, not me.)
  
  LikeLiked by 2 people
  - 12
    
    jpholbrook on July 26, 2025 at 3:18 pm
    Reply
    
    The Mac is a consumer product and absolutely does not need the accuracy the Geerling talks about.
    
    I just thought it was interesting that it was so difficult to handle. Since the Mac is Unix based, I tend to think of it as capable of handling anything any Linux system could do. But time is a tricky enough thing that unless you design the right support in, there are limits to what you can do. This is not a criticism of the Mac: it knows what it is and stays close to that remit.
    
    I really enjoyed Geerling’s other videos on the subject of highly accurate time keeping. It is indeed a rabbit hole.
    
    LikeLiked by 3 people
  - 13
    
    Duncan on July 26, 2025 at 3:47 pm
    Reply
    
    Agreeing with jpholbrook that the Mac is not a device one would seek if trying to maintain super accuracy. I suspect that Geerling is interested in this as a hobby, not as a practical solution (although I haven’t read through the rest of his material to confirm this). There are people who consider themselves to be Time-Nuts, who pursue this just for the fun of it.
    
    (See also the timeanddate web site for a decent library of articles that discuss horological matters.)
    
    LikeLiked by 1 person
- 14
  
  Duncan on July 26, 2025 at 3:39 pm
  Reply
  
  Thank you for the link to Geerling’s article. I’m posting here before wading through all that, although I see hints of how to approach a problem I’ve been trying to solve.
  
  I have a number of security cameras connected to a non-routed 10.x network (I will never attach a camera looking at my own property to the Internet!), all controlled by the excellent Security Spy software. However, since that network is isolated it can’t reach an external NTP server, which means the clocks on all the devices and the Mac itself drift from one another. Years ago I fumbled my way through setting up an old Mac Mini as an NTP server, which was also connected to the 10.x network, so at least they all stayed in sync with that machine, but the clock on the Mini still drifts on its own. (A lot.)
  
  So I bought an inexpensive USB-based GPS puck (originally sold for laptop use if one needed live location data) which also provides time data through the NMEA sentences that the GPS receiver spits out. (Have fun chewing through all that!) Even if one extracts the actual time data itself, that needs to be input to the Mac via the USB interface and used to set the system clock somehow.
  
  Before I go too far, I’m not looking for hyper-accuracy here; time to the nearest second (or even two seconds) is fine for security camera operation. As it is now, the current Mac’s clock will drift a number of minutes over the course of a year, so anything is an improvement.
  
  But now, scanning through Geerling’s writeup, even using the Mac-GUI ChronyControl app looks awfully tweaky, with initial setup steps being of a nature that I’ll forget the little landmines that need to be navigated if/when I have to troubleshoot all this a few years down the road.
  
  Unfortunately, setting up a GPS-synced Mac on a non-routed network is not a common application, so no one is likely to write and maintain a start-to-finish GUI app just for this task. And purchasing a standalone GPS-based NTP server remains quite expensive, at least for something that comes with readable English documentation.
  
  LikeLiked by 2 people
15

kapitainsky on July 26, 2025 at 3:09 pm
Reply

Between occasional glance at the clock on a church and GPS satellites beaming nanoseconds precise signals there were few other time keeping methods. Unfortunately they are slowly disappearing:

https://arstechnica.com/gadgets/2023/10/canadas-84-year-radio-time-check-has-stopped-because-of-accuracy-concerns/

I have seen in my IT life industrial computer systems using such signals to keep their time accurate. For various reasons they could not be connected to the Internet. I wonder what they use now – maybe GPS.

LikeLiked by 1 person
- 16
  
  Duncan on July 26, 2025 at 4:05 pm
  Reply
  
  “I wonder what they use now – maybe GPS.”
  
  Yes, with various degrees of accuracy depending on how much your department is willing to spend.
  
  Time Machines
  
  Meinberg
  
  Galleon
  
  There is a really promising standalone GPS-based NTP server that also has a useful front display:
  
  YK-1000H Chinese NTP server
  
  It looks like everything one would need for a simple out-of-the-box device for a non-routed network. Unfortunately, early reports of its setup and use indicate that you’re on your own when it comes time to configure and troubleshoot the device. I wish someone with a known reputation would offer this same package with full documentation, support, and a warranty.
  
  Like
- 17
  
  David C. on July 30, 2025 at 2:25 pm
  Reply
  
  I’ve seen many embedded devices use GPS or a cellular modem for clock synchronization. Of course, they don’t work if you’re in a building that blocks the radio signals.
  
  LikeLiked by 1 person
18

Iain on July 26, 2025 at 3:23 pm
Reply

There was utility for Mac OS 7 that would set the time via modem, I believe it would call NIST.

But that was 30 years ago and I cannot recall what the utility was! Do you recall such a thing?

LikeLiked by 1 person
- 19
  
  hoakley on July 26, 2025 at 4:22 pm
  Reply
  
  I used to use Vremya, as mentioned in the article. The first of its references is an instruction document from NIST that includes recommendations for older versions of Classic Mac OS, and worth reading. It’s only brief.
  Howard.
  
  LikeLiked by 1 person
20

Paul R on July 28, 2025 at 12:49 pm
Reply

Back before automatic syncing, the clocks on my old Macs were laughably inaccurate. They’d drift more than a minute every day. It was as if this futuristic high-tech thing on my desk had wind-up alarm clock inside.

LikeLiked by 2 people
- 21
  
  hoakley on July 28, 2025 at 7:36 pm
  Reply
  
  Mine too. I said much the same thing at the time, until we got NTP.
  Howard.
  
  LikeLiked by 1 person
- 22
  
  joethewalrus on July 28, 2025 at 11:21 pm
  Reply
  
  This doesn’t match my experience at all, but I only owned 2 Macs over that time, and I imagine it varied quite a bit based on architecture (for example, the first time I opened a Centris, I was astonished at just how much it differed from a Classic II, well beyond the obvious things like external display and expansion ports).
  Were your clocks powered the majority of the time from the grid, or from the PRAM battery? Where are you located? (I’m curious if 60 Hz countries, where I am, experienced better clock accuracy than 50 Hz ones.)
  
  LikeLiked by 1 person
  - 23
    
    ben luna on July 29, 2025 at 4:01 am
    Reply
    
    Hello, I wonder the same thing re: the differences between 50 and 60 Hz countries.
    
    I am a little surprised at the lack of accuracy on the Mac. It sound like Apple Watch and iPhone should be much more accurate ala https://mashable.com/archive/apple-watch-synchronized#TIIsFON85Gq5 but I don’t see anything preventing the Mac from using the same mechanism. Maybe this would be an interesting subject for a future article?
    
    Ben
    
    LikeLiked by 1 person
    - 24
      
      hoakley on July 29, 2025 at 8:38 am
      
      Sorry, but that article is an amazing piece of marketing bullshit!
      
      The Mac does use some of the same mechanisms as iPhones and Apple Watches. However, no Mac contains a GPS receiver, so unless you connect one yourself (which isn’t trivial), a Mac is always left using slightly less precise methods of syncing over a network.
      
      Very few Mac users ever need that higher accuracy though. We’re not talking seconds here, but milliseconds. Internal times in a Mac are precise (down to nanoseconds in many cases), it’s just that they aren’t as accurately synchronised to external reference clocks.
      
      Howard.
      
      LikeLiked by 1 person
    - 25
      
      ben luna on July 30, 2025 at 4:26 am
      
      Of course I would like to have a better source on the details, but that was the best that I could find. It does contain this excerpt which I thought was interesting:
      
      “First of all, we’ve curated our own network time servers around the world,” said Lynch. There are, by his count, 15 such “Stratum One”-level Network Time Servers (NTP) (one level down from an atomic clock), scattered around the world. They’re all housed in buildings with GPS antennas on the roof that talk, you guessed it, to GPS satellites orbiting the earth, which all get their time information from the U.S. Naval Observatory. In other words, those satellites are all getting their times from one, big orbiting system.”
      
      Or is that bullstratum one too?
      
      LikeLiked by 1 person
    - 26
      
      hoakley on July 30, 2025 at 1:11 pm
      
      AFAIK Apple has been hosting its own NTP servers in multiple locations around the world since at least 1998, when it first offered this service to Mac users. In those days, of course, they couldn’t use GPS, but Apple devices with GPS including iPhones and Apple Watches also use their own GPS data to sync their clocks.
      
      Although Macs don’t contain a GPS receiver, you can add one yourself, as others here have been discussing, and use that to sync your Mac’s clock more accurately than can ever be achieved using one of its NTP servers.
      
      GPS is now widely used for this purpose, and you’ll find many larger private networks, e.g. in enterprise, with their own GPS-based time servers little different from Apple’s NTP servers.
      
      When it comes to precise and accurate time to the user, Apple Watches aren’t really that special. Indeed, I don’t know of a way of them measuring and reporting time to the millisecond. One of the quirks of the human interface across Apple’s devices and even Macs is how fiddly it is to get high-resolution time from them. Even in dialogs, the human interface is reluctant to even deal with seconds!
      
      Howard.
      
      LikeLike
  - 27
    
    hoakley on July 29, 2025 at 8:30 am
    Reply
    
    At the time there were theories about 50 and 60 Hz mains frequencies, but if you think about it, the whole of the electronics inside a Mac is powered by DC, not AC, so it couldn’t have made any difference, neither did the internal battery, so long as it wasn’t flat.
    There are good design reasons for running internal clocks slightly on the slow side. Then when they do need to be corrected, the clock is moved forward. That avoids any problems that can arise with duplicated timestamps etc.
    Howard.
    
    LikeLiked by 1 person
    - 28
      
      David C. on July 30, 2025 at 2:41 pm
      
      I’ve seen devices where the wall-wart produces low voltage AC, and a chip inside the device counts cycles for various timing operations (along with an internal bridge rectifier to generate the DC power rails needed by the digital circuits).
      
      But I don’t know of any computer that did this. The Apple II, Mac, PCs, Ataris, Commodores, etc., all used (internal or external) DC power supplies. No AC power was delivered to the motherboard, so there would be no possible way to use it as a timing source (or for any other reason).
      
      Computers always used one or more onboard oscillator (typically a crystal) for generating the clocks needed by the rest of the system.
      
      On the embedded devices I work with today, one of those crystal oscillators is usually a 32.768 MHz part. This specific frequency allows a cheap 16-bit counter chip to generate a very accurate 1 kHz clock signal (the crystal increments the counter and the 15th bit is the output clock). This clock is in turn used to drive the real-time clock (increment the count of milliseconds with every tick) and derive (with additional circuitry) the timing for serial port bit-rates.
      
      LikeLiked by 2 people
    - 29
      
      hoakley on July 30, 2025 at 2:46 pm
      
      Internal time since Mac OS X is the Mach tick: in Intel Macs at 1 GHz for a tick every nanosecond, and in Apple silicon one every 125/3 = 41.66… nanoseconds.
      Howard
      
      LikeLike