Record and transmit measurement time as an unambiguous UTC timestamp, and apply the local time zone only when presenting data to a person. Control the device clock, the server receipt time and the sample order separately. This prevents the daylight saving time change from creating two identical hours, and it stops recorder drift from looking like a delayed structural response.
In short
- UTC defines the instant. The time zone defines the rules used to display that instant locally.
- A
10:15timestamp without an offset or time zone name is not enough for data exchange.- Measurement time and delivery time are two different pieces of information. A delayed frame must not shift history.
- Clock drift must be measured and limited on the device. UTC storage alone does not synchronise hardware.
- Integration acceptance should cover the DST change, late data, duplicates and a clock outside tolerance.
One sample has at least three times
A measurement timestamp is an unambiguous record of the instant when the device acquired the value, independent of when the data was sent or displayed. That distinction matters more than the choice of date format.
The first time is created during acquisition. The sensor or recorder performs a reading and assigns it an instant. The second appears during transmission: a frame may be sent immediately, after connectivity is restored or many hours later. The third is presentation time. A user in Warsaw wants to see local time, while someone analysing the same asset from London may choose a different zone.
If the database stores receipt time instead of measurement time, a communications outage changes the history of the physical phenomenon. Imagine a recorder that measured correctly overnight but sent the backlog at 07:00. Twelve samples from different instants did not happen at 07:00. They only reached the server then.
RFC 3339 defines the timestamp format for Internet protocols and requires a relation to UTC through Z or a numeric offset. 2026-07-09T06:15:00Z identifies one instant. 2026-07-09 08:15 does not say whether it means Warsaw, London, an operator setting or a clock after a time change.
In the data specification, it is therefore worth storing at least measurement time and the technical receipt time. The first builds the time series. The second makes it possible to calculate transmission delay and assess the link. How to describe these fields in a system acceptance process is also shown in construction monitoring data specification for the employer's requirements.
UTC, offset and time zone are not synonyms
UTC is the common reference scale for an instant. An offset, for example +02:00, says how far the local display differs from UTC at that instant. An IANA zone, for example Europe/Warsaw, is a set of historical and current rules that determine the offset for a location. Those rules can change by government decision.
RFC 9557 explains an important difference: an offset alone is not enough for local-time operations such as "the next day at the same time". A time zone contains the rules for offset changes. IANA maintains the zone database and updates it when zone boundaries, offsets or daylight saving rules change.
| Information | Example | What it is used for | What it does not resolve |
|---|---|---|---|
| UTC | 06:15:00Z |
Unambiguous event ordering | What local users see |
| Offset | +02:00 |
Converting a specific instant | Rules for future and historical dates |
| IANA zone | Europe/Warsaw |
Local presentation with DST rules | Whether the device clock is correct |
| Receipt time | 06:17:12Z |
Measuring transmission delay | When the reading was taken |
In a measurement database, the most predictable arrangement is simple: store measurement time and technical events in UTC, and keep the preferred time zone as a user, project or organisation setting. The interface converts the time only at display time. A technical export should preserve unambiguity and state whether the values are in UTC or include an offset.
This separation also makes post-incident discussions clearer. You can say: the reading was taken at 06:15 UTC, it arrived at 06:17:12 UTC, and the operator saw it as 08:15 Warsaw time. Each sentence refers to a different fact.
DST creates one hour that does not exist and one hour that occurs twice
Daylight saving time (DST) does not change the order of instants in UTC. It changes the local description of those instants. In spring, a certain range of local hours does not exist. In autumn, some hours appear twice, with two different offsets.
Illustrative example for the Europe/Warsaw zone: during the spring change in 2026, the local clock jumps from 01:59:59 UTC+1 to 03:00:00 UTC+2. The local hour 02:30 does not occur. During the autumn rollback, the local hour 02:30 occurs twice, once with offset +02:00 and again with +01:00.
| Local notation | Possible instants | Entry assessment |
|---|---|---|
Spring 02:30, without offset |
Zero | Non-existent time, reject |
Autumn 02:30, without offset |
Two | Ambiguous time, reject |
02:30+02:00 |
One | Unambiguous for this sample |
00:30Z |
One | Unambiguous and easy to sort |
Do not "fix" a non-existent hour by silently shifting it to 03:30. That changes the event time without the sender's knowledge. The same applies to the autumn duplicate: choosing the first or second occurrence without an offset is guessing. A better contract rejects such input and requires correction at the source.
The DST test is inexpensive and exposes many errors. It checks the date parser, validation, sorting, charts, exports and alarm messages. If the team postpones it until the first autumn after launch, production becomes the test environment.
Clock drift: a small error that grows every day
Clock drift is the growing difference between the device time and the adopted reference source. It happens because the local oscillator does not measure time perfectly. Temperature, ageing, power supply and component quality affect the rate of that difference.
Illustrative example: if a clock gains an average of 4 s per day, after 30 days the difference will be about 120 s. Two recorders on opposite sides of an asset can drift in different directions. Then an event that physically happened at the same time looks on the chart like propagation delayed by several minutes.
NIST describes the use of a synchronised clock in sensor components to assign the timestamp at acquisition time or to trigger a measurement at a specified time. The required accuracy must follow the use case. Slow-changing monitoring may tolerate a different difference than the analysis of a short vibration pulse, where traces from multiple axes are compared.
The requirement "the device must have the correct time" is too weak. The specification should define:
- the synchronisation source and behaviour after it is lost;
- the maximum permitted difference from the server;
- the frequency of checks and resynchronisation;
- the behaviour of the frame when the clock is outside tolerance;
- how the error is logged and how backlog measurements are recovered;
- the test after a power restart and after a long period without connectivity.
UTC solves the semantics of storage. Synchronisation solves the physical alignment of clocks. You need both.
A practical drift check should record pairs: device time and trusted source time, measured as close together as possible. From successive differences, calculate the average change per day and the worst deviation. Do not subtract the full network delay from the result if the protocol does not measure it bidirectionally. In plain HTTP, the moment of request receipt includes transmission, queuing and device processing time. Such a test is good at detecting a large problem, but it does not replace a precise synchronisation protocol when millisecond alignment is required.
Five acceptance tests for time that should be part of the contract
The tests below can be run in a pilot integration. Each one has an input, an expected result and evidence. It is not enough to look at a correct chart from one sunny day.
Test 1: unambiguous format
Send a valid RFC 3339 timestamp in UTC, then a version without an offset. The first sample should be accepted according to the contract. The second should be rejected or handled explicitly, without default guessing of the server time zone.
Test 2: DST transition
Test a non-existent and an ambiguous local time. Require an error that lets the integrator find the cause. Then send equivalent, unambiguous instants in UTC and verify their order on the chart and in the export.
Test 3: clock outside tolerance
Shift the device time beyond the agreed deviation. Verify whether the platform rejects the frame, returns information needed for correction and logs a diagnostic event. Then restore the time and confirm that acquisition returns to normal without changing old timestamps.
Test 4: late arrival and duplicate
Send an older sample after a newer one, then repeat the same instant. The history must be sorted by measurement time. A retry should not create two points for the same device and instant. It also has to be clear whether the retry overwrites the value or is rejected.
Test 5: two presentation zones
Open the same range as users with different time zone settings. The UTC instants must remain identical, although the local labels will differ. A server-side notification should not depend on a browser time zone chosen by chance.
Add a power-loss test to this five-part set if the recorder works autonomously. Disconnect power for longer than the clock backup can hold, start the device without the network, then restore connectivity. Make sure the first new samples did not receive the factory date, the buffered history preserved the original instants, and the device does not send data before synchronisation is complete. This scenario often reveals a defect that is invisible in a normal desk test.
Acceptance evidence checklist
- [ ] The input frame for each test was preserved.
- [ ] The response and error code were recorded.
- [ ] Measurement time was compared with receipt time.
- [ ] The chart, table, export and notification were checked.
- [ ] The behaviour after retrying the same sample was confirmed.
- [ ] The zone and version of the rules used in the test were documented.
These tests extend the usual completeness check. For more on freshness, gaps and cadence metrics, read the article on measurement data SLA.
How this looks in Inclify
Inclify stores measurements and API time values in UTC. In the interface, the presentation time zone is selected according to the user setting, then the project and organisation, and finally the browser's local time zone may be used. Server-side notifications do not rely on the browser time zone.
When data is accepted, the platform also checks the device clock. When its time differs from the server by more than 30 s, the frame is rejected as invalid, and the response contains the information needed by the device to set its time. This behaviour must be accounted for in recorder software and tested before field installation.
Backlog data can be sent later over the same HTTP/JSON channel with its original UTC timestamps. The write is idempotent for the combination of project, device and measurement instant, so repeating the same sample updates the existing point instead of creating a second one. The contract does not use a separate sequence number. Diagnostics are easier with a communication log containing the raw request and response, stored for the configured period, by default seven days.
In practice, the integration test should cover correct time, a 30-second tolerance breach, a repeated sample and the later submission of historical data.
Limitations: what correct time does not solve
Matching timestamps do not prove that the measured value is correct. A device may have a good clock and a broken sensor. It can also assign time after a long acquisition sequence, even if the analysis assumes the start instant. The contract should define which instant the timestamp refers to.
UTC does not store civil context by itself. If a report must reproduce the local hour applicable under specific rules, the zone name and the current IANA database are needed. Versions of that database may differ between systems, especially after a sudden legal change.
Idempotence based on device and instant has a consequence: two valid samples with exactly the same timestamp cannot coexist as separate records. If the hardware measures faster than the timestamp resolution, the time precision has to be increased or the contract has to be expanded.
What remains is evidence. Local labels in a screenshot are convenient, but in an incident analysis it is worth keeping UTC values, the raw frame, receipt time and the time zone used. The same separation is needed when monitoring data must support dispute analysis.
FAQ
Is it enough to store local time with an offset?
For a single sample, a correct offset identifies one instant unambiguously. However, it does not replace the time zone name for operations that depend on future or historical DST rules. In a measurement series, it is simplest to store the instant in UTC and apply the project or user zone at presentation time. RFC 3339 describes data exchange.
Does UTC mean the same thing as GMT?
These names should not be used interchangeably in technical specifications. UTC is the modern time scale maintained in the international metrology system. GMT has historical and civil meanings. In a protocol, write Z or an explicit offset according to RFC 3339, instead of relying on the abbreviation "GMT".
What should be done with a late sample?
Store it under the original measurement time, provided it passes contract validation. Do not shift it to receipt time. Keep the transmission metadata separately so delay can be calculated. Rules for alarms on historical data need to be designed deliberately so that a late sample does not pretend to be a current event. Also document the cause of the delay, if it is known.
How often should a recorder clock be synchronised?
There is no single interval for all applications. It depends on clock stability, the required alignment between devices, the dynamics of the phenomenon and how long the device works without a network. First define the maximum allowed error, then measure the actual drift and choose the synchronisation frequency with a margin. After a power loss or connectivity loss, perform an additional check.
Can a time change create duplicates in the database?
Yes, if local time is stored without an offset. During the autumn change, the same local notation refers to two different instants. In UTC, these are two different timestamps, so the order stays correct. The parser should reject ambiguous input instead of choosing one interpretation on its own.
What should be checked when charts from two devices are shifted?
Compare device time against a common source, measurement time against receipt time, the acquisition interval and the transmission delay. Also determine whether both devices timestamp the start or the end of the measurement cycle. Only after excluding the time layer should the shift be interpreted as a property of the physical phenomenon. The error root-cause tree can help with this.
Sources and further reading
- IETF / RFC Editor, RFC 3339: Date and Time on the Internet: Timestamps.
- IETF / RFC Editor, RFC 9557: Timestamps with Additional Information.
- IANA, Time Zone Database.
- National Institute of Standards and Technology, Sensors 1588.
- IETF / RFC Editor, RFC 5905: Network Time Protocol Version 4.
What next
Do not start with a discussion about the field format. Take one frame, shift the device clock, send it late and repeat it during a DST scenario. Arrange a conversation with the Inclify team if you want to run five time tests on an existing recorder before connecting it to online monitoring.