The Need Time bit is a DNP3 outstation raising its hand to say that it does not trust its own clock. Every event it timestamps carries the time from that internal clock, so if the clock is wrong, every event in your sequence-of-events record is wrong too, even though the values themselves are fine. Operators often ignore this flag because nothing is obviously broken, but a stale clock quietly corrupts the exact analysis you rely on after a trip or an alarm cascade. This page explains what IIN1.4 is asking for, how the master clears it by writing the time, why devices keep re-asserting it, and what happens when you leave it set.
DNP3 Need Time IIN Flag in one line: The DNP3 Need Time flag, IIN1.4, is set by an outstation to tell the master that its internal clock has drifted, was reset, or was never set, and it needs a time synchronization before its event timestamps can be trusted. The master clears it by writing the current time to the outstation, typically using Object 50 (Time and Date), after which the outstation resets the bit. Devices re-assert Need Time on a configured interval, so it is a normal recurring request rather than a fault, but leaving it unserviced means events get inaccurate or default timestamps that ruin sequence-of-events analysis.
DNP3's real value in fault analysis comes from timestamped events. When a status point changes or an analog crosses its deadband, the outstation records not just the new value but the moment it happened, using its own internal clock. Those timestamps let you reconstruct the order and timing of a cascade, which relay tripped first, which alarm followed, and how many milliseconds apart, long after the event scrolls off a live screen. The entire discipline of sequence-of-events analysis depends on those timestamps being correct and consistent across devices.
If an outstation's clock is wrong, everything it timestamps inherits that error. A device whose clock never got set may stamp events with a default epoch time, which is why you sometimes see events dated to 1970 sitting in an otherwise current record. A device whose clock has drifted stamps events that are internally consistent but offset from real time, so its events appear to happen seconds or minutes before or after events from a correctly synced device. Either way, when you line up events from multiple outstations to figure out what happened first, the picture is distorted and you can draw exactly the wrong conclusion about cause and effect.
This is why Need Time is not a cosmetic warning. The outstation is telling you, in advance, that it does not have confidence in the clock that stamps its events, and that any event it produces until you sync it should be treated with suspicion. The values are still real, the point states are still accurate, but the when is unreliable. In a system where the whole reason you deployed DNP3 was accurate event ordering, an ignored Need Time flag hollows out the benefit while leaving everything looking normal on the surface.
The master clears Need Time by giving the outstation the correct time. In DNP3 the current date and time is carried in Object 50, the Time and Date object, and the master performs a time synchronization by writing that object to the outstation with the present time. Once the outstation accepts the write and updates its clock, it clears IIN1.4 to indicate it no longer needs a sync. Some deployments use a more elaborate procedure that accounts for the communication delay between master and outstation, measuring the round trip so the written time lands accurately, which matters on slow or high-latency links where the transit time is a meaningful fraction of the timestamp precision you care about.
The mechanics are usually automatic. A properly configured master watches the IIN field on every response, and when it sees Need Time set, it schedules a time write without operator intervention. This is why on a healthy system you rarely have to think about the flag, it appears and is cleared within one polling cycle. The moment to pay attention is when Need Time stays set across many cycles, which means the master is either not configured to service it, is failing to write successfully, or the outstation is rejecting the time write. A persistently set Need Time bit is the signal that the automatic clearing has broken down.
It helps to remember that clearing the flag and keeping the clock accurate are two related but distinct jobs. Writing Object 50 once clears the current request, but the outstation's clock will drift again, so the master needs an ongoing time-sync policy rather than a single write at startup. On systems where the master itself gets time from a reliable source, that upstream accuracy flows down to every outstation each time the master services Need Time, which is why the quality of the master's own clock discipline ultimately governs how trustworthy every field timestamp is.
Outstations do not raise Need Time once and stay quiet forever. Each device re-asserts the flag on a configured time-sync interval, effectively a self-imposed reminder that its clock may have drifted enough to warrant a fresh sync. A device with a poor internal oscillator or a tight accuracy requirement re-asserts more often, while a device with a good clock and looser needs re-asserts rarely. This periodic re-assertion is normal and healthy, it is the mechanism that keeps field clocks bounded to real time. What you want to see is Need Time appearing on its interval and being cleared promptly each time, a steady heartbeat rather than a stuck bit.
The failure symptom to watch for is timestamps that are visibly wrong: events dated to 1970, events that appear out of order relative to physically simultaneous ones, or two devices that disagree by a consistent offset. Any of these means a clock somewhere is not being synced. In a multi-device SOE record, a single unsynced outstation can make an entire fault reconstruction misleading, because its events slot into the timeline at the wrong position and suggest a false sequence. Servicing Need Time promptly, and confirming that the sync actually took, is what keeps the timeline honest.
Accurate SOE timestamping is a strong reason to prefer a monitoring layer that treats the IIN flags as data rather than noise. Because a platform like Merobix logs the Need Time bit over time alongside the events themselves, an engineer can see at a glance which outstations are re-asserting on schedule and being cleared versus which one has had Need Time set for hours, and can correlate a suspicious timestamp in a trend directly to a clock that was never synced. That turns an invisible, silently corrupting condition into a visible operational metric, so the person analyzing a trip is not unknowingly trusting events stamped by a drifted clock in a distant cabinet.
It asks the master to send the outstation the current time so the outstation can correct its internal clock. The outstation raises IIN1.4 because its clock has drifted, was reset, or was never set, and until it is synced its event timestamps are unreliable. The master responds by writing the time, usually through Object 50, and the outstation clears the flag once it accepts the new time.
A timestamp near 1970 usually means the outstation's clock was never set and is sitting at its default epoch, so every event it stamps carries that default time. This is exactly the condition Need Time is meant to catch, because the device is generating events with a clock it knows is wrong. The fix is to make sure the master is servicing the Need Time flag and successfully writing the current time to that outstation.
Each outstation re-asserts Need Time on a configured time-sync interval, which reflects how quickly its clock drifts and how tight its accuracy requirement is. A device with a poor oscillator or strict timing needs re-asserts more frequently, while one with a good clock re-asserts rarely. Seeing the flag appear on its interval and get cleared promptly is normal and healthy; seeing it stuck on for long periods means the master is failing to service it.
This page references the protocol specifications published by the organizations below. Editions, product capabilities, and documentation change over time - confirm current requirements and specifications directly with the source.
Last reviewed: July 27, 2026. Merobix is not affiliated with, endorsed by, or sponsored by these organizations; their names are used only to identify the standards and products discussed.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.