System time, clocks and their syncing in macOS

Of all the features of our Macs, the one we most take for granted must be time. From the moment it starts up, we expect its clocks and timekeeping to be accurate, whether it’s the clock at the far right of the menu bar, or times recorded in its logs. This article explains how to ensure that works, and what to do when it doesn’t.

Settings

Unless your Mac is one of the few that isn’t connected to the Internet, set it to check time and clocks by syncing with Apple’s Time Server over the network. Standard settings for doing that are 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 your Mac’s current location.

In some cases, a local network time server may be preferred by setting the source to a different network address. This can be useful within active local networks, where it’s important that all network devices are synchronised to the same source, although that should work just as well using Apple’s time service. Some computers allow you to specify multiple time servers, in case some of them aren’t reachable. macOS only uses one, and if you do provide a list of NTP servers, only the first will be used.

The most common problem arises when the time zone can’t be set automatically using Location Services. This is buried more deeply, in Location Services in Privacy & Security settings. Click on System Services, and ensure you have allowed access to Setting time zone, and that Location Services is enabled.

One common situation where this doesn’t work is in Virtual Machines, which normally aren’t able to get an accurate location as they can’t access Wi-Fi directly. You’ll then have to set the time zone manually.

Like daylight savings or summer time, time zones don’t change the time of the system clock, but are corrections applied to times read from that and presented in localised form for you to see.

Importance

Accurate system clock time is of considerable importance in many respects, as it’s used for the timestamps of files and directories, and can have implications for security. APFS uses transaction identifiers (XIDs) to keep track of the order of events within its file systems, so isn’t reliant on timestamps, but other features may not have such an independent mechanism. Backups are an obvious example, where decisions can be confused by contradictory file creation and modification times.

Sometimes users deliberately change the system clock and disable its online updates to run a Mac using past time, for example to work around an expired security certificate. Although that may work well at the time, it can lead to strange problems resulting from disordered time sequences, and should be used with caution.

NTP service

Accurate and synchronised time has been required since long before the Internet, and is available using other means. Navigation and other systems have been using radio time signals for many decades, and most recently GPS satellites provide highly precise time. The disadvantage to these is that they require special radio receivers that aren’t built into Macs, although most of Apple’s devices now include GPS receivers. Another way to get accurate time is from a local atomic clock, but they’re beyond our budget.

The alternative is an NTP server like time.apple.com, but that poses another problem, as the server has to be polled over the network, and that takes time in both directions. To account for that, macOS has to calculate a time offset as the difference in absolute time between its clock and that of the NTP server, and the round-trip delay for the whole request. It can then estimate how much it needs to adjust the Mac’s clock time to be in sync with the server.

Because time offset and round-trip delay vary in each check with a server, macOS may perform several checks and use those to derive best estimates.

One important confounding factor here is anything that leads to long delays in connecting with the NTP server, and the most common cause of those is using a VPN service. Routing NTP connections through your VPN service can cause inaccurate local clock times.

timed

As far as I’m aware, prior to macOS 10.13 High Sierra, macOS used an ordinary NTP client to connect to NTP servers and correct its clock time. Apple then replaced that with 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 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.

SNTP

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 handle this through timed and the com.apple.timed subsystem.

It’s sometimes suggested to use sntp to adjust the system clock using the command
sudo sntp -sS time.apple.com
Although this runs and reports offsets from the NTP server, it requires sudo if it’s to perform clock adjustments using adjtime, and it’s not clear what effect it has on timed.

Log

timed and clock adjustment occurs relatively late during the boot process, as it requires timed to be running with access to network connections. However, you may be confused by a pair of prominent Boundary entries that appear before synchronisation:
02.452702045 Boundary === system wallclock time adjusted
02.524229049 Boundary === system wallclock time adjusted
where the initial system boot entry was made at 00.0 seconds. Those are only internal adjustments.

timed and com.apple.timed subsystem start entries after those, first giving the version and build of timed, then announcing its start
02.741880893 com.apple.timed cmd,start

timed‘s cached state is then read from disk, and TMTimeSynthesizer is used to set system time
03.421952009 com.apple.timed Setting system time to Tue May 20 08:24:04 2025 from TMTimeSynthesizer

Initially, without a network connection, timed has to wait to sync with the NTP server
03.476943969 com.apple.timed We want time and don’t have network! Keeping timed alive until network comes up, since we are beyond our wanted threshold.

Eventually, the NTP server is reachable
04.200660943 com.apple.timed Fetching NTP time.
04.249860048 com.apple.timed Received time Tue May 20 08:24:05 2025±0.01 from “NTP”

Another three time estimates are obtained from APNS
07.982021093 com.apple.timed Received time Tue May 20 08:24:09 2025±35.00 from “APNS”
13.667812108 com.apple.timed Received time Tue May 20 08:24:14 2025±35.00 from “APNS”
14.488466024 com.apple.timed Received time Tue May 20 08:24:15 2025±35.00 from “APNS”
leading to adjustments to system time. I don’t think that the APNS referred to here is Apple Push Notification Service, could it be Apple Primary Name Server, perhaps?

Slower is better

As a general principle, correcting the clock backwards to an earlier time would be bad news, as it would confuse anything that relies on time order. This can be seen, for example, in the autumn/fall when daylight savings or summer time ends in many countries, and localised clocks are set back in time. This ensures that for a period of roughly an hour, localised times duplicate those from the previous hour, and is particularly difficult to handle in log extracts.

If the system clock is going to err, then it’s better for it to be slightly slow, which allows adjustments forward in time that can’t result in duplication of timestamps.

Summary

Unless your Mac isn’t connected to the Internet, set its time and date automatically using time.apple.com as the source, and enable it to set its time zone automatically through Location Services.
Virtual Machines that can’t use automatic time zone settings should have their time zone set manually.
A local network time server may be a preferred source, but macOS will only use one NTP server.
Deliberately backdating a Mac’s clock can have untoward effects, and should be used with caution.
Use of a VPN can delay syncing with the NTP server, and can cause clock problems.
From macOS 10.13, macOS relies on timed to sync time.
Using sntp to force sync clock corrections is still available, although it isn’t clear whether it’s effective.
Trace timed activity in the log using the subsystem com.apple.timed.

References

NTP in Wikipedia