I realize that since Raspberry Pi doesn't have a hardware real-time clock built in, some issues with accurate timekeeping may present themselves, even when persistence across reboots is not a requirement.

This can largely be mitigated by running a NTP daemon that will continuously correct the local time, but NTP is not an option if the Raspberry Pi is not connected to a network.

So if I leave a Raspberry Pi turned on with accurate time in the beginning, how much should I expect the reported time to drift from the actual local time?

And how about between reboots?

  • It will be software keeping time when not connected who t it? I'd say time keeping software is inherently accurate. – Jivings Aug 1 '12 at 23:23
  • You talking about a 10 minutes maximum at worst per year(extreme temps of -20 and lower / +60 and higher)(optimized for 20degrees operation) . Its not that bad. A real-time clock now a days is only used for atomic time keeping.. like.. very precise mathematical functions that need to measure execution time or something hectic. Allot of devices drop 32khz crystal because oscillators are good enough for generating RF signals or Video signal without serious complications. – Piotr Kula Aug 2 '12 at 12:40
  • @ppumkin Do you have any sources for this? I was kinda expecting less accuracy due to the reasons that Chris Stratton mentioned (missed interrupts and such). – Tibor Aug 2 '12 at 12:41
  • Sorry- Just my general knowledge in the field and experience of using oscillators instead of crystals. Missing interrupts is going to be mega extreme! If it were that bad everybody would not be doing it. – Piotr Kula Aug 2 '12 at 12:44
  • This question is really more about Raspbian than about the Pi itself. And the idea of keeping a Pi running continuously for over a year is so unlikely that it makes the above statistics insignificant by comparison to what happens during reboot. – SDsolar Jun 19 '18 at 3:39

There are really two issues:

1) The accuracy of the oscillator itself - which has variables such as uniqueness, age, temperature, etc. A quick catalog perusal suggests typical microprocessor clock crystals are on the order of +/- 10-100 parts per million

2) If there is anything which might cause timekeeping errors relative to the crystal oscillator. That would be things like missed interrupts, or transition issues if the clock used is after a PLL multiplier - or affected by clock throttling (if it's used).

Incidentally, NTP unless very well implemented can actually make precise self-relative timing worse in the short run, since it means the local clock can be changed to be consistent with an external authority, rather than remaining consistent with itself.


It will depend on the crystal they used, maybe 10ppm or so. You can't really count on it unless it is specified somewhere though. You may be able to use GPS if not connected to a network. Otherwise a RTC chip can be added.

You'll need something better than just software time if there is a chance the RPi can lose power or crash.

I hope to be hooking up a RTC to the GPIO sometime soon


Interpreting the question to be asking about a Raspberry Pi running Raspbian.

The OS is the dominant influence in how the Rapberry Pi keeps time.

Answer: Without an external source, the internal clock is highly unpredictable in terms of keeping time on its own.

Recent case studies:

This is a plot from a Raspberry Pi 3 B datalogger which suddenly lost utility power for about an hour:

enter image description here

You can clearly see that when power came back on, it booted and restarted the data logging.

But the Raspbian clock jumps back in time.

Then you can see it jump forward to the correct time as soon as it gets an update from time.nist.gov

The National Bureau of Standards recommends using time.nist.gov because it is a smart URL that finds the quickest and most accurate time available. Both Linux (ubuntu and Raspbian) and Windows default to pools which can be many hops away from the Master Clock.

How do I set Raspbian to use the primary time server time.nist.gov?

Here is a newer plot from the same system again.

Since it interrupted yesterday (see plot above) I used sudo init 0 to shut it down properly, in order to image the SD card with Win32DiskImager on a PC.

It takes a while, as can be seen here.

enter image description here

In this one you can see Raspbian initially restarted its clock right where it left off. It looks like it had logged good data (jumps up) within a minute.

Then it shows what happens when it receives the time update. It jumps forward to the right.

The amount it jumps forward (a couple of hours) is time that was missed by Raspbian while the SD card was being imaged.

Here's a surprising twist.

The system simply froze up. Both red and green lights on, no flickering.

Announced (using espeak) within minutes by the main server's ping-based cron job which monitors the data loggers for just such an occurrence. So it wasn't off more than a few minutes.

Pulled power for a few seconds. Rebooted it - LEDs look normal.

Here is how this glitch affected the data logging:

enter image description here

The Raspbian clock jumped forward by 2 hours when the system was rebooted.

Then the time update from time.nist.gov sets it back.

Answer: Without an external source, the internal clock is unpredictable in terms of keeping Real Time on its own.

How do I set Raspbian to use the primary time server time.nist.gov?

  • 1
    I can confirm that. Without internet connection or RTC date and time from raspberry is useless. – Łukasz Jakubek Jun 19 '18 at 14:24
  • There are VLF radio receivers with clock demodulators in them. For example, Here is one tuned to 60 KHz can hear WWV in Colorado all over North America. amazon.com/CANADUINO-60kHz-Atomic-Clock-Receiver/dp/B01KH3VEGS These are the same modules they use in some clocks. They work with Arduino and Pi. – SDsolar Jun 19 '18 at 19:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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