Has anyone got the time? How High Sierra has changed time synchronisation

High Sierra has changed a lot of macOS internals. Not just graphics with Metal 2, the introduction of machine learning or VR, but subtle and largely undocumented features, like how macOS keeps its clock in synchronisation with reference time sources.

Up to and including Sierra, macOS was much like any other Unix. Every so often, a daemon named ntpd fires up and checks over your network connection with a standard time server, and (using a complex protocol) makes any necessary adjustment to your Mac’s system clock. This is a fiddly process, because there is inevitable delay between the time information being sent by the standard time server and your Mac being able to respond to it. If you want to read the full detail, it is described in man ntpd, and I have written a more approachable account here.

There is also a local time server daemon named timed, which is intended to synchronise your Mac’s clock with others on the same local network. timed is a common feature to most other varieties of Unix, and documented in man timed. It is important when you run network services which expect close synchronisation between the different system clocks, such as Kerberos, but is seldom used otherwise.

If you have upgraded to High Sierra, try typing man timed in Terminal, though, and you’ll have a surprise. Gone is the lengthy and traditional account of the daemon. It has been replaced with a novel timed which is new in High Sierra, and now performs both synchronisation with standard time servers (as used to be done by ntpd) and local synchronisation (as for timed). Only there aren’t any options, commands, or anything else for you to mess with. macOS has taken all that away from you.

High Sierra’s timed appears to be scheduled and dispatched using the undocumented DAS and CTS systems, and is intended to fire up every hour.

You’re probably aware that Sierra suffers from a serious bug in DAS, which results in its scheduling falling apart if your Mac is left running for a week or so. If High Sierra were to suffer the same problems, then this would not only mean that Time Machine’s automatic backups would not be run regularly, but that your Mac’s clock could start to drift from standard time. Fortunately, High Sierra has a new DAS system, and early indications are that it does not suffer from that bug.

There isn’t much that you can do with the new timed daemon. Its configuration is stored in /etc/ntp.conf, which just lists the standard time server set in the Date & Time pane. It is worth checking that your High Sierra installation has set that correctly: many systems have defaulted to using the main time.apple.com server in the US, rather than the local Asian or European service.

Presumably, if you want to use a different standard time server, timed will happily talk NTP with it as if it were running the old ntpd.

The property list controlling timed is at /System/Library/LaunchDaemons/com.apple.timed.plist, which is protected by SIP anyway, and not particularly helpful for users or sysadmins.

What is more interesting is the cached state of timed, kept in /var/db/timed/com.apple.timed.plist. This is a log of the ‘TM’ command history, and gives details of the last attempt to use NTP to synchronise with a standard time server, the equivalent Mach time, and a lot of internal diagnostic information about timed and synchronisation attempts.

[Added 1800 27 Oct] There is a third property list with exactly the same name, located at /var/db/timed/Library/Preferences/com.apple.timed.plist, which contains two additional settings, for NtpUseServicePort and TMAutomaticTimeOnlyEnabled, which are boolean properties of unknown purpose, and probably best not fiddled with.

This new version of timed is apparently derived from the same daemon which has been running in iOS since iOS 5.0. It contains quite un-Mac-like features such as Airplane Mode too.

If you use any software or hardware product which depends on traditional ntpd or timed commands, then this change in High Sierra will also certainly break it. If you do anything which is dependent on accurate time, you might like to keep a careful watch on how this change works out. In theory, as the code has matured in iOS, it should be fairly free of bugs by now.

If you do experience problems with clock drift or synchronisation, you should still find useful entries in the unified log, but you should also take a careful look at /var/db/timed/com.apple.timed.plist, which might answer your question more quickly.

Thanks to Johnson’s comments here for alerting me to this hidden change, and to xz4gb8 for discovering yet another property list for timed (see his comment below).