Ask Different is a question and answer site for power users of Apple hardware and software. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

In the recent weeks I've noticed each morning that my clock would be behind by 2-3 minutes. I've noticed that opening the 'Date & Time' dialog from System Preferences will trigger the clock to resynchronize to Apple's time servers. I am running OS X 10.7.4 Lion on an 8,2 MacBook Pro.

What might be causing this lack of automatic resynchronization?

EDIT: I compared my /etc/ntp.conf file to a peer's also running Lion, and we noticed that my file contained:

0000000: 7365 7276 6572 2074 696d 652e 6170 706c  server time.appl
0000010: 652e 636f 6d2e 0a              

while his had:

0000000: 7365 7276 6572 2074 696d 652e 6170 706c  server time.appl
0000010: 652e 636f 6d                   

His last modification date on the was mid-2010, while mine was last modified only a week or two ago (around when the issue started?). I certainly did not manually edit the file. Possibly related?

EDIT 2: I noticed that, if I change my time server in 'Date & Time' to, say, Asia, my /etc/ntp.conf file becomes:

0000000: 7365 7276 6572 2074 696d 652e 6173 6961  server
0000010: 2e61 7070 6c65 2e63 6f6d 2e0a  

complete with trailing 0x2e character. So, it seems that OS X adds the trailing . automatically, but a fresh Lion system does not contain this trailing character. Still unsure whether this is affecting the synchronization though.

EDIT 3: It's been 24 hours since I changed the time server to 'Apple Asia' and then back to 'Apple Americas' -- no time drift. Bizarre.

share|improve this question
Just a general comment... I would have thought the computer clock should keep better time, without having to constantly resync with a time server? My desktop PC is set to resync once a week, but does not loose any noticeable time in that period. Years ago when I used to service PCs, a slow system clock was often the result of a failing lithium button battery?! – w3d Jun 13 '12 at 16:06

Looks like some special characters got inserted at the end (especially the 0x2e part which represents a simple .) and OS X now interpretes this as part of the server name. To fix, just run

sudo echo server > /etc/ntp.conf
sudo chown root:wheel /etc/ntp.conf

from the Terminal.

As to why you have this issue I have no clue.

share|improve this answer
I suspected as much. I've already edited the file to not contain the 0x2e character and rebooted, and am basically waiting to see whether I accumulate significant drift again. Still, I would love to know how this could have happened and why opening 'Date & Time' causes it to apparently not use the ntp.conf file to resync? – noffle Jun 13 '12 at 15:04
Changing the server from within "Date & Time" would probably have solved the issue as well. Opening the pane without any changes doesn't trigger a configuration file update. – patrix Jun 13 '12 at 15:07
When changing the time server via the "Date & Time" dialog, OS X actually changes the ntp.conf file to contain the 0x2e character and trailing newline. I don't think this is the cause. – noffle Jun 14 '12 at 17:26
Ah, when I change the server name via "Date & Time" I get the trailing . as well. Seems to be a Lion issue then. – patrix Jun 14 '12 at 20:38
up vote 1 down vote accepted

Since I (experimentally) made the following change, I've ceased to have clock drift issues, despite by /etc/ntp.conf file's contents not technically changing:

Open the Date & Time settings dialog, change the time server from Apple Americas/U.S. ( to Apple Asia ( and then back to Apple Americas/U.S. ( From there, my daily time drift has ceased to occur.

This is a rather unsatisfying answer -- I'd love to change the select answer if anyone comes up with the real, underlying cause.

share|improve this answer
Although not a definitive answer, I have experienced .plist files becoming corrupted and causing all sorts of problems that are seemingly fixed by making a 'radical' preference change, and then going back to 'normal.' This forces the .plist file to be written afresh, overwriting the corrupt bits. – IconDaemon Jan 1 '14 at 2:47

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.