Time stamps you can trust: clocks, time zones and synchronisation in data loggers

A water level of 3.42 m means little on its own. It becomes information when tied to a moment: 3.42 m at 02:15, rising from 2.90 m an hour earlier. Every reading is a pair, a value and a time stamp, and most attention goes to the first. This article is about the second: how a data logger knows what time it is, how that knowledge decays, which time zone to write down, and what to do when a clock turns out to have been wrong for weeks.

Why the time stamp matters as much as the value

A time stamp is the date and time attached to a reading. It is used in at least four ways:

• Merging stations. If one gauge in a basin runs five minutes fast, its rain appears to start before its neighbours', and a storm seems to move the wrong way.
• Rainfall intensity. Intensity is depth divided by duration, so it depends on where each interval starts and ends, and a clock error can put rain into the wrong interval or even the wrong day. The WMO Guide to Instruments and Methods of Observation (WMO-No. 8) notes that the accuracy of station clocks needs special attention to ensure correct sample intervals and time stamps [1].
• Flood travel time. The time a peak takes to travel from an upstream gauge to a town sets warning lead time. It is a difference between two clocks, so both clocks' errors enter it.
• Matching alerts to events. After a flood, people ask when the water crossed the danger level and when the alert went out. If logger, server and messaging system keep time differently, that sequence cannot be reconstructed.

An illustrative example. Suppose an upstream gauge records a peak at 10:00 and a gauge 25 km downstream records it at 12:30, so the travel time is 2 h 30 min. If the downstream logger clock is 4 minutes slow, its stamp reads 12:26 and the travel time appears to be 2 h 26 min, an error of about 3 %. Small, but invisible, and carried into every lead time computed from those two stations.

How logger clocks keep time, and why they drift

A data logger keeps time with a real-time clock (RTC): a small counter, powered by a backup battery, that counts the oscillations of a quartz crystal. WMO-No. 8 describes a battery-powered 24-hour real-time clock as "an essential part" of data processing at an automatic weather station, adds that clock accuracy "requires special attention to guarantee correct read-outs, sample intervals and time stamps", and notes that some stations synchronise the clock to broadcast radio time signals or GPS [1].

Low-power clocks commonly use a 32.768 kHz tuning-fork crystal, which a published study describes as the most common type in wireless sensor nodes [3]. Two properties set how fast it drifts.

Tolerance, in parts per million

No two crystals oscillate at exactly the same frequency [2]. The difference is given in parts per million (ppm), the fractional frequency offset multiplied by one million. A fractional frequency offset produces the same fractional time error, Δf/f = Δt/T [2], so the clock error grows in direct proportion to elapsed time:

time error (s) = offset (ppm) × 10⁻⁶ × elapsed time (s)

1 ppm × 86,400 s per day = 0.0864 s per day

A peer-reviewed study of clock synchronisation in sensor networks gives the typical tolerance of an uncompensated tuning-fork crystal as about ±20 ppm at 25 °C [3].

Worked example. A logger with a +20 ppm crystal, kept at 25 °C:

20 × 10⁻⁶ × 86,400 s   = 1.73 s per day
1.73 s × 30 days       = 51.8 s per month
20 × 10⁻⁶ × 31,536,000 s = 631 s ≈ 10.5 minutes per year

Temperature

Tuning-fork crystals have a parabolic dependence on temperature. Frequency is highest at a turnover temperature, normally 25 °C, and falls on either side of it:

f = f0 · (1 + β · (T − T0)²)

where T0 is the turnover temperature and β is the temperature coefficient. The study above quotes β = −0.034 ± 0.006 ppm/°C² for a typical crystal with T0 = 25 °C [3]. Because β is negative, the clock always runs slow away from 25 °C, whether the enclosure is hotter or colder.

Worked example. A logger box on a Himalayan bridge in winter averaging 0 °C:

β · (T − T0)² = −0.034 × (0 − 25)² = −21.3 ppm
21.3 × 10⁻⁶ × 86,400 s = 1.84 s slow per day ≈ 55 s per month

This adds to the tolerance: a −20 ppm crystal in that box runs about 41 ppm slow, losing 107 s a month. A sunlit box at 45 °C gives the same −13.6 ppm as one at 5 °C, because the curve is symmetric about 25 °C.

A temperature-compensated crystal oscillator (TCXO) measures its temperature and corrects the frequency, to 0.5 to 5 ppm [3]. Quartz also ages, its frequency changing slowly over months and years [2]. A better oscillator reduces drift; it does not remove the need to correct the clock.

Try the numbers for your own site:

Where a logger can get the correct time

Since every local clock drifts, a logger needs an outside reference.

GNSS. WMO's Manual on Stream Gauging suggests setting logger clocks from a connected GPS receiver, "for instance once a week" [8]. GPS time has no leap seconds, so it is ahead of UTC by the leap seconds added since 6 January 1980. The offset is broadcast by the satellites and usually applied by receivers [4], but check that your firmware stores UTC, not raw GPS time.

NTP. The Network Time Protocol (NTP), version 4, is defined in IETF RFC 5905 [5]. Offsets below 125 ms are corrected by slewing, gently speeding up or slowing the clock. Larger offsets are corrected by stepping, setting the clock directly, after the offset has persisted beyond a 900 s stepout period [5]. A step forward leaves an apparent gap in the series; a step back creates duplicate stamps. The IETF best-practice document recommends at least four independent, diverse time sources for operators who need accurate time [6]. In India, CSIR-National Physical Laboratory maintains the national time scale UTC(NPLI) and offers NTP service [9].

Cellular time. Under 3GPP TS 22.042, network time is optional for the operator and its expected accuracy is in the order of minutes [7]. Use it only as a sanity check.

A practical arrangement: an RTC for continuity, GNSS or NTP for regular correction, a log entry for every correction, and a clock check against a reference at every site visit [8].

IST or UTC?

Coordinated Universal Time (UTC) is the world's reference time scale. Indian Standard Time (IST) is UTC plus 5 hours 30 minutes. NPL describes IST as "UTC(NPLI) plus 5:30 hours" [9]. India has no daylight saving time, so it is tempting to store everything in IST. We recommend storing UTC anyway.

1. The global system works in UTC. WMO standard times of observation are defined in UTC (for example 0000, 0600, 1200 and 1800 UTC) [10].
2. No hidden assumptions. A stamp with no zone is ambiguous by 5 h 30 min, enough to move a night storm into the afternoon, and no range check will catch it.
3. Mixed systems. Servers, databases and messaging services may run in UTC. A station in IST beside a server in UTC can make an alert appear to precede the event that triggered it.
4. Display is separate from storage. Users should see IST on dashboards, converted at display time from the stored UTC value.

Write the offset every time. ISO 8601 is the international standard for writing dates and times. It orders the elements year, month, day, hour, minute, second and covers UTC and local time with an offset to UTC [11]. IETF RFC 3339 is a profile of ISO 8601 for internet use; it defines Z as an offset of 00:00 and offsets as "local time minus UTC" [12]. The same instant can then be written unambiguously in either zone:

2025-07-15T03:00:00Z          (UTC)
2025-07-15T08:30:00+05:30     (IST, same instant)
15/07/25 8:30                 (ambiguous: which zone, which date order?)

WMO-No. 168 asks for times in UTC or local standard time "using 24-hour clock designations" [13]. For automatic stations, UTC in ISO 8601 form is the safest choice.

Period-start or period-end: what does "09:00" mean?

Rainfall, sunshine and flow volume are accumulations over an interval. A single stamp can label the interval by its start or by its end, and the two differ by a whole interval.

The IMD rainfall day. India Meteorological Department (IMD) operational rainfall is a 24-hour total ending at 0830 IST, which is 0300 UTC. IMD's standard operating procedure for hydromet services describes its daily rainfall summary as the 24-hour rainfall "observed till 03 UTC", gauges as "recorded at 0830 Hrs. IST", and bulletin entries as rainfall "recorded at 0830 hrs IST of today" [14]. The total is labelled by the end of the period, so the figure for 15 July contains rain that fell on the morning, afternoon and night of 14 July.

WMO practice points the same way. WMO-No. 168 says the designated time of a set of climatological observations should be the end of the time over which the set is taken [13], and the WIGOS Manual notes that most variables are observed over the 10 minutes before the reported time [10].

What this means for a logger:

• Label each interval by its end, in UTC, and record the interval length with the data, for example 2025-07-15T03:00:00Z, 15 min, 4.2 mm.
• Do not compute a "daily total" from midnight to midnight and then compare it with IMD's daily rainfall. A midnight-to-midnight IST total and an 0830-to-0830 total cover different rain.
• Check imported data. Before merging another network's records, find out whether its stamps mark the start or the end of each interval. A one-interval shift raises no error; the data just look slightly wrong.

Detecting time errors

Useful checks:

• Logger time vs receive time. Compare each stamp with the time the server received it. A steadily growing difference is drift; a sudden change is a reset or a step.
• Gaps and duplicates. A clock stepped forward leaves a gap; one stepped back produces duplicate or out-of-order stamps.
• Comparison with neighbours. Rain onset at nearby gauges, or a flood peak at upstream and downstream gauges, should be in a plausible order.
• Site-visit checks. Compare the logger clock with a reference at every visit and write down both times [8].
• Default-date resets. A logger whose clock resets to a default date after a backup-battery failure will produce stamps from the wrong day or year.

Correcting time errors without corrupting the record

WMO-No. 168 distinguishes gradual drift, which can be corrected by scaling over the period, from discrete events such as clock stoppage, which leave a gap that can be estimated only under limited conditions. It also asks agencies to keep data in original form and to store evidence of any modifications [13].

For drift, the usual correction is linear between two known points:

correction(t) = −E × (t − t0) / (t1 − t0)

where t0 is the last time the clock was known to be correct, t1 the time the error E was measured (logger time minus reference time), and t the logger time of each record.

Worked example. A logger was synchronised at 2025-07-01T00:00:00Z. At a site visit on 2025-07-31T00:00:00Z the logger reads 41 s ahead of the reference. A record stamped 2025-07-16T00:00:00Z is half way through the period, so its correction is −41 × 0.5 = −20.5 s, and its corrected time is 2025-07-15T23:59:39.5Z.

Rules that keep the record trustworthy:

1. Never overwrite the original stamp. Store the raw logger time and the corrected UTC time in separate fields.
2. Flag every corrected value, with the method (linear drift, offset, manual) and the date it was applied.
3. Never silently shift data. An unrecorded shift looks exactly like correct data and cannot be undone.
4. Re-aggregate after correction. If a correction moves readings across an interval boundary, recompute the totals for both intervals rather than editing one.
5. Do not interpolate across a clock stoppage as if it were drift. Mark the gap.
6. Keep corrections reversible, so a better correction can be applied later.

A short checklist

• Store every time stamp in UTC, in ISO 8601 form with Z or an explicit offset.
• Display IST to users, converted at display time.
• Label accumulations by the end of the interval and store the interval length.
• Use GNSS or NTP (with several servers) to correct the real-time clock, and log every correction.
• Check and record the logger clock against a reference at every site visit.
• Expect steps, gaps and duplicates when a clock is corrected, and handle them in processing.
• Keep raw and corrected times side by side, with a flag for the method.
• Know the rainfall-day convention (0830 IST, 03 UTC, labelled by its end) before comparing with IMD data.

Key points

• A ±20 ppm crystal drifts about 52 s a month at 25 °C, and runs slower in hot or cold enclosures.
• GNSS and NTP are good references; cellular network time is coarse.
• Store UTC with an explicit offset; display IST.
• IMD's rainfall day ends at 0830 IST (03 UTC) and is labelled by its end.
• Correct time openly, keeping original and corrected stamps.

Getting time right is mostly a matter of design decisions made once, in the logger and in the data platform, and they shape how we build the data loggers integrated in our monitoring devices and the Visiflow (Device Cloud) platform that stores their readings with their metadata. For how logging, telemetry and the server fit together, see what is RTDAS.

References

1. World Meteorological Organization, Guide to Instruments and Methods of Observation, Volume III: Observing Systems, WMO-No. 8, 2024 edition, Chapter 1 "Measurements at automatic weather stations" (real-time clock). WMO publication page.
2. M. A. Lombardi (NIST), Frequency Measurement, Chapter 42 in Measurement, Instrumentation, and Sensors Handbook, second edition, CRC Press, 2014: Δf/f = Δt/T, quartz oscillators, temperature compensation and aging. tf.nist.gov.
3. J. M. Castillo-Secilla, J. M. Palomares, J. Olivares, Temperature-Compensated Clock Skew Adjustment, Sensors 13(8), 10981–11006, 2013. doi:10.3390/s130810981.
4. National Institute of Standards and Technology, How is UTC(NIST) related to Coordinated Universal Time (UTC), International Atomic Time (TAI), Greenwich Mean Time (GMT), USNO time, GPS time and Zulu time? nist.gov.
5. D. Mills, J. Martin, J. Burbank, W. Kasch, Network Time Protocol Version 4: Protocol and Algorithms Specification, IETF RFC 5905, 2010. rfc-editor.org.
6. D. Reilly, H. Stenn, D. Sibold, Network Time Protocol Best Current Practices, IETF RFC 8633 (BCP 223), 2019. rfc-editor.org.
7. 3GPP, Network Identity and TimeZone (NITZ); Service description; Stage 1, TS 22.042. 3gpp.org.
8. World Meteorological Organization, Manual on Stream Gauging, Volume I: Fieldwork, WMO-No. 1044, 2010: 4.4.5 (timers) and 4.8.1 (clock, timer and battery check). WMO publication page.
9. CSIR-National Physical Laboratory, Time and Frequency Metrology (UTC(NPLI), IST and NTP service). nplindia.in.
10. World Meteorological Organization, Manual on the WMO Integrated Global Observing System, WMO-No. 1160, 2023 edition updated in 2024: definition of standard time of observation; Appendix 5.1, 5.1.2. WMO key WIGOS publications.
11. International Organization for Standardization, ISO 8601: Date and time format (ISO 8601-1:2019). iso.org.
12. G. Klyne, C. Newman, Date and Time on the Internet: Timestamps, IETF RFC 3339, 2002. rfc-editor.org.
13. World Meteorological Organization, Guide to Hydrological Practices, Volume I: Hydrology – From Measurement to Hydrological Information, WMO-No. 168, 2008 edition, updated in 2020: 2.5.3 (frequency and timing of observations), 9.5 (data registers, original records and adjustments for clock drift and stoppage). WMO Hydrology Publications page; full text: copy hosted by Agência Nacional de Águas, Brazil.
14. India Meteorological Department, Standard Operating Procedure: Hydrometeorological Services in India, Hydromet Division, March 2021. mausam.imd.gov.in.