DNP3 events three hours off and nothing wrong: a master on local time
IEEE 1815 recommends that DNP3 time be UTC. Many masters write local time instead, a convention set years ago and kept for every outstation since. Every event timestamp is then off from UTC by the time zone, exactly, and a check that compares RTU time with UTC flags every single event. The right comparison is with the master's own clock.
The setup
RTU 51, synced every 30 minutes by a master that writes local time, UTC-3. Three hours of capture, nothing else unusual.
What the capture shows
| 3 hours | Value |
|---|---|
| Offset of the time the master writes | -3 h 00 min (-10,799,972 ms) |
| Time writes | 6 |
| Event delay, measured against that offset | 0.1 to 2.1 s, median 1.0 s |
| Events in the future | 0 |
- The offset is constant across all six writes: a convention, not drift.
- Measured against the master's own offset, every event arrives 0.1 to 2.1 seconds after it happened. Master and outstation agree, and the sequence of events is correct.
- The same events measured against UTC would all look three hours old. A tool that does that turns a convention into 98 false alarms.
What to check
- Find the master's offset from its time writes first, and judge every event against it.
- Check that every outstation on the master uses the same convention. A mix of UTC and local time across outstations is a real fault: their events cannot be merged into one sequence.
- Watch the daylight saving changes: a master on local time with DST moves its offset twice a year, and events around the change can repeat or skip an hour.
Try it on your own capture
ComputingSphere DNP3 finds the time offset the master writes and judges every event against it, so a local-time convention is reported as an offset, not as a fault. It only reads what already went over the wire. This capture is among the examples of every free account, to reproduce every number here; or upload your own: the Free plan covers 1,000 messages a month.