Ubuntu's clock is off by about a half hour:

Ubuntu Time & Date v. The official U.S. time

Where do I even start troubleshooting this?

It's allegedly being set "automatically from the Internet". How can I verify that "the Internet" knows what time it is?


Ubuntu has had plenty of time to communicate with the Internet:

$ date; uptime
Fri May 18 05:56:00 PDT 2012
 05:56:00 up 12 days, 10:48,  2 users,  load average: 0.61, 0.96, 1.15

This time server I found via a web search does appear to know the correct time:

$ date; ntpdate -q north-america.pool.ntp.org
Fri May 18 05:56:09 PDT 2012
server, stratum 2, offset 1752.625337, delay 0.10558
server, stratum 2, offset 1752.648597, delay 0.10629
server, stratum 3, offset 1752.672466, delay 0.11829
18 May 05:56:18 ntpdate[29752]: step time server offset 1752.625337 sec

There aren't any reported errors related to NTP:

$ grep -ic ntp /var/log/syslog

After rebooting, the time was automatically corrected and the following appeared in /var/log/syslog:

May 18 17:58:12 aux ntpdate[1891]: step time server offset 1838.497277 sec

A log of the offset reported by ntpdate reveals that the clock is drifting by about 9 seconds every hour:

$ while true; do ntpdate-debian -q | tail -n 1 >> 'drift.log'; sleep 16m; done
$ r -e '
    attach(read.table("drift.log", header=FALSE))
    clock <- as.POSIXct(paste(V1, V2, V3), format="%d %b %H:%M:%S")
    fit <- lm(V10~clock)
    plot(clock, V10, xlab="Clock time", ylab="Time server offset (s)")
    mtext(sprintf("Drift rate: %.2f s/hr", fit$coefficients[[2]]*3600))

Clock time v. Time server offset

  • Background: ntp is a great tool to maintain accurate time. But, it takes a finite time (several minutes, or even hours) to get to current time from incorrect time. This is related to ntp-servers (your choice of) and your Internet latency to these. @Floyd has outlined a shortcut to quickly force correct time. But better time (and use of ntp) requires careful selection of ntp-servers.
    – david6
    May 18, 2012 at 22:28
  • My car does this... drives me crazy... I have to roll back the time 20 minutes every week...
    – TheXed
    Sep 13, 2012 at 23:16
  • The first thing I would try doing is changing the battery on the motherboard....
    – TheXed
    Sep 20, 2012 at 16:37

4 Answers 4


ntp does well at keeping your computer set to the right time, and does that without ever running it backwards--which would be a bad thing for some programs you might be running.

It not only sets the time, but it makes continuous adjustments to how your computer keeps time so that its time is not only right at one instant in time, but stays close to the real time (within dozens of milliseconds, not dozens of minutes). It adjusts both phase (the time) and rate (how fast the clock "ticks"). ntp never makes the clock run backwards. It can take a long time to establish how fast to tick the clock after a reboot, so ntp keeps track of the drift in a file called /var/lib/ntp/ntp.drift . Since you aren't running ntp none of this happens.

ntp is not as popular as it once was because sleeping laptops and desktops, and virtual machines stop it from running some of the time. It's designed to run every once in a while on its own schedule on a computer that is running all of the time, and in the real world where time is continuous. That's probably why it isn't installed by default on the modern workstation. [For Vmware, see this]

Instead ntpdate is run when the network interface is brought up. When a sleeping laptop is awakened it reestablishes the network connection, ntpdate is run, and the time is again correct. If the machine's hardware clock is pretty accurate, and the network is brought up and down fairly often, that's generally good enough for most people.

For some reason stock ntpdate doesn't alway run. Use ntpdate-debian instead in this case. Syntax for the for.mer is something like ntpdate ntp.ubuntu.com, for the latter it is ntpdate-debian

In the absence of one of those things, then ntp is a better way to keep time.

Systems are designed to take a timer interrupt every so often and update its idea of the time every interrupt. As long as the hardware timer is running to spec. the time doesn't drift too much. If the hardware timer isn't, the time will drift more (all such clocks will drift some, for the same reason your wristwatch or battery controlled clock will. Clocks plugged into the wall are synced to the time by the frequency and phase kept by your power company).

Most computer timers are controlled by a crystal controlled oscillator circuit on its integrated circuits. Despite the crystal, they run faster and slower depending on the environment, mostly the temperature. Unless you have some time syncing software installed we don't know about, I'd say your system's clock is off spec.

If you were to run ntp for a day or two it would store information in /var/lib/ntp/ntp.drift that would indicate how much it would have to adjust the rate at which your operating system time advances per interrupt in order to match your hardware clock rate with the real time it gets over the internet. Keeping the file the same and just starting and stopping ntp after a minute after that (assuming you keep the /var/lib/ntp/ntp.drift file unchanged) might do a lot to correct for this if the clock bias ntp sets remains after ntp ends. I'm not sure of this detail.

I suspect the value ntp would store in /var/lib/ntp/ntp.drift is far different than mine.

If this machine is kept running all of the time, however, the best thing to do is to install ntp and let it do its thing. See the other answers for details on getting the time right before starting it. I run ntp on my desktop and ntpdate on my laptop.

An interesting possible alternative, adjtimex, is mentioned in this answer by nealmcb.

If your system is not kept running all of the time, running ntpdate at boot time seems like a good option.

Warning some software can freak if the computers time goes backwards. Running ntpdate after boot could cause this to occur.

One gotcha, that can be a problem: As I recall ntp expects the time to not be too far off. If it is, trying to act conservatively, ntp won't adjust the time at all. If you are in this situation it makes sense to do both--run ntpdate at boot to get the time initialized to the right time, and then let the ntp run to keep it running to provide accurate timekeeping. In particular a bad motherboard battery can cause this error, as can booting a computer that's been off for a long time.

  • Great explanation John! Just one little thing - the date/time on most motherboards is maintained by a separate RTC (real time clock), which uses its own 32.768 KHz crystal (because dividing that frequency by 2^15 gives you precisely one second), and the FSB clock, which usually is at 100+ MHz, doesn't have anything to do with date-time-keeping - if so over/underclocking would mess it up -- instead it's usually crystal drift in the RTC module/circuitry. Can you look this issue up and reply to the comment and/or edit your answer to reflect this?
    – ish
    Jun 8, 2012 at 22:57
  • I'll do both! I've removed the mention of over-clocking as I think it is improbable, as I had said. The RTC is just used to set the time at boot time, however. As your comment mentions, it is only accurate to 1 second. The man rtc page says: "RTCs should not be confused with the system clock, which is a software clock maintained by the kernel and used to implement gettimeofday(2)..." Don't know whether the system clock is related to the FSB clock. Looking at the kernel config the latest Ubuntu precise i386 kernel has the system clock being updated at 250Hz. Thanks for the comment! Jun 9, 2012 at 0:04
  • @izx On my laptop system the kernel is using the HPET as its clocksource. It's configurable. Wikipedia says that this is part of the southbridge function. I don't know what that says about its relationship with the FSB, but I gather the FSB is part of the northbridge. Jun 9, 2012 at 0:47
  • Thank you, John and @izx. I'm delighted by the comprehensiveness of this. izx, I hope you won't take it personally that I've marked it as accepted instead. I think it will be the better read for future visitors.
    – ændrük
    Jun 9, 2012 at 1:26
  • @ændrük : no problem at all, as you can see I appreciated John's thoroughness very much as well.
    – ish
    Jun 9, 2012 at 1:30

- Usually time is only synced once upon each boot or wakeup-from-sleep

So the problem appears to be either that Ubuntu's default time server (what is it?) has the incorrect time, or Ubuntu is not setting the time automatically from the Internet.

No, Ubuntu's time server is correct, and it is setting the time automatically from it.

The problem is that is usually occurs only once upon each bootup (or to be more precise, each time a network interface is brought up - whether from shutdown, sleep or hibernation). Based on your uptime, it's safe to say it wasn't sync'd in more than a week. And your system clock is running slightly fast for some reason.

- Set up an hourly cron job to sync if you don't reboot often, or your server/desktop never goes to sleep

Your best bet is to set up a cron-job, I'd say hourly if you want super-precise time. The easiest way to do that is:

  • sudo editor /etc/cron.hourly/ntpsync

Add the following lines:


ntpdate ntp.ubuntu.com #or your choice of server
  • save, exit and sudo chmod +x /etc/cron.hourly/ntpsync

You can put this in /etc/cron.daily instead if you would like, for once per day.

  • Spot on. I'm accepting this for correctly answering my question of why the clock is wrong, but I'm skeptical of that workaround. I'll have to learn a little more about this before I decide what action to take.
    – ændrük
    May 19, 2012 at 15:14
  • If you set the server of your choice in the ntp.conf file, do you need to redefine it here?
    – Snekse
    Dec 19, 2012 at 18:58

This can happen if you have installed the ntp time daemon and the time on you machine is too far off to correct quickly.

To fix it open a terminal and do

  sudo service ntp stop
  sudo ntpdate swisstime.ethz.ch
  sudo service ntp start

What this does:

  1. Stop ntp daemon
  2. Set clock
  3. Time should now be right
  4. restart ntp daemon

If you don't have ntp installed, do it with

  sudo apt-get install update

Update: Using ntpdate in a cron job, as has been recommended here, leads to subtle problems.

The ntpdate will make the time 'jump' every hour or so. Using ntp avoids this problem, because it will adjust time by skewing the clock. Also, while selecting an ntp server in the neighborhood gives even higher accuracy, it's not necessary. The default ntp config file has several servers in it and the server automatically compensates for any delays.

Bottom line: - use ntp - if you are far of, shutdown ntp, run ntpdate once and restart ntp.

  • /etc/init.d/ntp doesn't exist. This is a fairly recent Ubuntu 12.04 installation and I haven't deliberately changed anything related to time.
    – ændrük
    May 18, 2012 at 13:14
  • Then i recommend installing it.
    – Floyd
    May 18, 2012 at 13:15
  • As much as is possible, I prefer not to meddle with system-wide configuration and services. If this file isn't installed by default, why should it be necessary for the default Time & Date settings to work?
    – ændrük
    May 18, 2012 at 13:17
  • 1
    Is the time correct after a reboot? I suspect that the clock update just runs ntpdate once. Some systems have the problem that the to system clock maintained by linux runs much too fast. I have had that in particular with systems running as virtual machines.
    – Floyd
    May 18, 2012 at 14:00
  • 1
    If this problem persists after reboot or shutdown , it might be your CMOS cell gone dead in MOBO.
    – atenz
    May 18, 2012 at 15:27

I had a similar problem and it was caused by something in the firewall. In the end I added the hourly cron job but added the -u argument to ntpdate to get it to use a none standard port.

My problem was caused by Ubuntu not actually checking if ntpdate worked but automatically assuming that it would work.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .