Saturday, April 5, 2014

Tiger time ... was six hours ago? (updated for 10.5)

One of our more interesting trouble tickets was one where the user's incorrectly set clock caused SSL certificate validation to fail (they kept appearing expired), leading TenFourFox to refuse to load other items such as style sheets, concluding they were also insecure.

The root cause of this problem is that 10.4 systems have an annoying tendency to lose synchronization with an NTP timesource (NTP being the typical protocol used by network time servers). This is a problem Apple has acknowledged, and has a service article on with an official remedy (essentially, to put iburst into /etc/ntp.conf). Unfortunately, this approach isn't a complete solution: while it does reduce initial negotiation time, systems like mine (and the user's) with long uptimes without sleep or shutdown will still eventually go out of sync.

UPDATE: There is apparently some argument over whether this was really fixed in 10.5. The good news is that the approach below should work for any version of Mac OS X with ntp.

As the Apple article points out, the first and easiest way to reestablish the connection is either by rebooting, or unchecking and then re-checking the time server checkbox in System Preferences. If your system is powered on and off regularly you may not have a need even to do this much, though you may want to make the iburst change to make any time change occur more quickly when your computer restarts. Similarly, if your computer is only intermittently connected to a network, you'll be reestablishing the connection periodically anyway. My iBook G4 falls into this category, so I left it alone.

On the other hand, my quad G5 and my Sawtooth G4 file server are always running and always connected to a network, and I have a local NTP timesource they should be syncing to. For these systems, I actually turned off syncing to a timeserver in System Preferences. Instead, in, I sudo tcsh and crontab -e. This opens a root shell (which sudo should ask you for a password for, right?) and edits the regularly scheduled cron task table. To the bottom of this file, add

2 * * * * /usr/sbin/ntpdate -s

Save the file in your editor (crontab should confirm that you changed root's cron job table). Every hour, at two minutes past the hour, this line will query the Apple time server and force your computer's clock to immediately sync to it. If you use a local timesource, substitute its hostname for You might want to immediately ntpdate -s after editing the crontab to make the clock immediately correct.

Because it uses a "manual" method, this approach doesn't require a constantly open socket to the timeserver and makes changes instantaneous to boot. Checking even less frequently than hourly will probably work too, but you can experiment with that yourself.

Properly maintaining your computer's clock is a necessary component of security because SSL certificates and access tokens and credentials are always timelimited. Worse than having a clock set such that certificates appear expired is to have your clock set such that bogus expired and possibly previously exploited credentials appear valid. Make sure that Tiger time is the right time.

The G5 service article is next.


  1. "unchecking and then re-checking the time server checkbox in System Preferences"

    I noticed early on that my G3 iBook's internal clock runs too fast by several seconds a day even though "set time and date automatically" is checked. So this "uncheck/re-check" is what I've been doing regularly for years on all my Macs since 10.2 if I wanted to make sure that system time is correct. I assumed the time was only synched with the server once when the Mac is restarted, which rarely happens, and I never questioned this behavior. I'm still doing this on my 10.5. PowerBook.

    By the way, leads to a 404 page. I'd like to find out whether the problem was solved in 10.5 or if I should add the cron task on 10.5 as well.

    1. Odd, the link works fine here.

      This link alleges that 10.5 also suffers from NTP drift, but I don't have any way of confirming that. However, the approach above should work on any version of Mac OS X that has ntp.

  2. This would explain why I was always having so many issues way back when in using Autosave and Autobackup on QuarkXPress 6.5 Those two features, because of a bug in QXP will go out of whack and create a whole bunch of useless temporary files (sometimes deleting the real file) if the clock on your Mac isn't in sync with the clock on the server.

    Back then I made our IT guy install a Time server on our WinSBS 2003 box we have and link it to, but even so our production Macs which are on 24/7 got out of sync so I had to shut this feature off.

    Glad to finally know what part of the problem with that app bug is.


Due to an increased frequency of spam, comments are now subject to moderation.