Your prototype records sensible readings, and every row has a date and time. After a week in the field, though, its events no longer line up with another device's log. Both clocks were set before deployment. Why are they now telling different stories?
For a team building an environmental logger or a device used away from a network, the useful question is how much timing error the task can tolerate. A clock that is fine for hourly room-temperature trends may be unsuitable for deciding which of two events happened first. Settle that before choosing a more expensive clock or adding frequent network updates.
Real-time clock accuracy is usually quoted in parts per million (ppm). This note turns that number into an offline allowance and lists what to check on the assembled prototype. It is a planning calculation, not a long-duration measurement of a particular board.
Turn the clock specification into seconds you can use
One ppm is a rate difference of one second per million seconds. If a clock's total rate error stays within ±20 ppm for the whole interval, the drift from that rate is bounded by about 1.7 seconds per day. A clock can run fast or slow, and the sign matters when you compare two devices.
The calculation is:
drift allowance in seconds = error in ppm × elapsed seconds ÷ 1,000,000
For an assumed constant rate error:
- ±20 ppm: ±1.728 s after one day, ±12.096 s after seven days, ±51.84 s after thirty days.
- ±50 ppm: ±4.32 s, ±30.24 s and ±129.60 s.
- ±100 ppm: ±8.64 s, ±60.48 s and ±259.20 s.
These are worked examples, not specifications for every RTC. They exclude the error already present when the clock was set and the delay between a sensor event and its timestamp. Check whether a quoted ppm value covers the assembled clock across its operating conditions or only a crystal at one specified temperature.
Allow for the whole timestamp, not just the oscillator
Suppose a timestamp may be at most ten seconds from the reference. If setting the clock can already leave two seconds of error, only eight remain for drift before any other delay. With a verified ±20 ppm rate bound, eight seconds is roughly 4.6 days offline. That is a simplified planning limit, not a validated resynchronization interval.
Comparing two independent loggers takes another step. One at +20 ppm and another at −20 ppm separate at 40 ppm, about 3.46 seconds per day, even if they started together. "The two logs must agree within ten seconds" is a different requirement from "each clock must stay within ten seconds of the reference."
A tidy CSV file does not establish accurate timing. Decide where the timestamp is taken: when a reading becomes available, when software processes it, or when it is written to storage. For a slow environmental trend, a modest delay may be acceptable. For event ordering, its size and variation may decide whether the data answers the question at all.
Check the conditions inside the finished device
NXP's RTC timekeeping accuracy application note, dated May 2026, separates temperature response, initial crystal tolerance, aging and circuit effects. A room-temperature number does not describe operation through changing temperatures. Read the device and crystal specifications together, and do not assume an external RTC automatically gives the accuracy the project needs.
The practical question appears in a SparkFun community discussion from 2020. Participants described different timekeeping behavior under different deployment conditions, including a warm enclosure. Those are user reports, not a controlled comparison, but they point to the condition to check: the electronics see the temperature inside the enclosure, which may differ from the room or outdoor air.
The options are to choose a clock specified for the required conditions, compensate a characterized error where the hardware supports it, or synchronize often enough from a suitable reference. Each has a different integration cost. A network update helps only if the network is actually available when the design needs it, and a better clock helps only if the rest of the timestamp path preserves its accuracy.
Make the next prototype test answer the deployment question
Before testing, write one requirement in plain language, for example: "After seven days without a connection, each recorded reading must remain within the agreed tolerance of the reference." Say whether the tolerance applies to one logger or to the difference between several. Choose a reference and comparison method with uncertainty small enough to judge that requirement.
Then record the initial offset, let the assembled device run through representative conditions, and compare at planned intervals without silently correcting it. Keep temperature, firmware version and any resets or synchronization events with the results. A single end-point comparison can hide changes during the run, and an automatically corrected clock can make the drift look smaller than it was.
These are proposed checks; we have not run a long-duration test for this note. If the clock is corrected during normal use, keep a record of each correction and a sample sequence number, so a time jump does not make data look missing or duplicated. Keeping the calendar through a power interruption is a separate check from keeping accurate time while running.