A leap second is an extra second occasionally inserted into the world's civil time, UTC, to keep it aligned with the slightly irregular rotation of the Earth. It sounds like a curiosity, but the way it is applied can briefly stall or rewind a clock, and that small discontinuity is exactly the kind of thing that trips up systems that assume time only ever moves forward at a steady rate. This guide explains what a leap second is, how it can produce duplicate or backward-moving timestamps that break historian ordering and sequence-of-events, and the mitigation strategies operators should understand.
Leap Second in one line: A leap second is an extra second added to UTC to keep clock time in step with the Earth's rotation, applied so that one particular minute contains sixty-one seconds instead of sixty. For SCADA, the concern is that inserting a second can make a clock repeat or step, producing duplicate or out-of-order timestamps that can corrupt event ordering unless the time source handles the adjustment gracefully.
The civil time everyone uses, UTC, is derived from extremely stable atomic clocks that tick at a perfectly uniform rate. The Earth's rotation, however, is not perfectly uniform; it varies slightly and, over long spans, tends to run a touch slow compared with atomic time. If nothing corrected for this, atomic time and the actual position of the sun would gradually drift apart. A leap second is the correction: an occasional extra second inserted into UTC so that clock time stays closely aligned with where the Earth actually is in its rotation.
It helps to distinguish two timescales. There is a continuous atomic timescale that simply counts seconds without any adjustments and never skips or repeats, and there is UTC, which follows that atomic timescale but is periodically nudged by whole leap seconds to track the Earth. The gap between them grows by one second each time a leap second is added. Systems that need a clean, monotonic count of time sometimes prefer to work in the continuous atomic timescale internally precisely because it never contains a leap second.
Leap seconds are not scheduled on a fixed calendar; they are announced in advance by the international body responsible for timekeeping when the measured difference between the two timescales grows large enough to warrant one. They are almost always inserted at the very end of a chosen day, so the affected minute runs from second fifty-eight to fifty-nine and then to an unusual sixtieth second before rolling over. That extra tick is where all the trouble for computer systems comes from.
Most software is written on the quiet assumption that time always moves forward, one second at a time, and never repeats a value. A leap second violates that assumption. Depending on how a system handles it, the clock may present the same second twice, or it may be stepped backward by a full second when the correction is applied, so that a later reading carries an earlier timestamp than one that came before it. Either way, for one moment the timeline is no longer strictly increasing, and any logic that trusts timestamps to be unique and ordered can misbehave.
In a historian, this shows up as duplicate or backward-moving timestamps around the insertion moment. Two distinct readings can end up stamped with the same instant, making it ambiguous which came first, or a value can appear to have been recorded before the one that actually preceded it. Sequence-of-events analysis is especially vulnerable, because its entire purpose is to establish the exact order of closely spaced events, and a one-second rollback right in the middle of an event cascade can scramble that order at precisely the wrong time.
The failures are subtle because they are brief and rare, which is what makes them dangerous. A leap second passes in a moment and only happens once every few years, so a system can run for a long time without ever exercising that code path, and the bug lies dormant until the day it triggers. By then the corrupted data is already in the record, and it can be hard to recognize after the fact that a handful of misordered or duplicated points trace back to a leap second rather than to a device or network fault.
The most common mitigation today is called leap smearing. Instead of inserting the whole extra second at one instant, a smeared time source spreads the correction out over a window of hours around the event, running its clock a tiny fraction slow so that it gently absorbs the extra second without the clock ever stopping, repeating, or stepping backward. Time stays strictly increasing the entire way through, which keeps every downstream system happy, at the cost of the clock being very slightly off from strict UTC during the smearing window. For most industrial monitoring, that brief, tiny offset is a far better trade than a discontinuity.
The practical advice for operators is to know exactly how each of their time sources handles a leap second, because inconsistency is its own hazard. If one server smears the correction and another applies it as a sharp step, the two can disagree by up to a second during the event, which can misalign data collected from different paths. The safest posture is for every clock in the chain to handle leap seconds the same way, ideally by smearing, so the whole fleet moves through the event smoothly and in agreement rather than each stumbling over it differently.
For a cloud SCADA platform such as Merobix, the goal is that a leap second passes without leaving any mark on the data. That means preferring time sources that smear the correction so timestamps stay monotonic, being prepared to recognize and reconcile the brief duplicate or backward-moving timestamps that a non-smearing field device might produce, and never letting a one-second oddity around a known leap second be mistaken for a real process event. Handled well, a leap second is a non-event for the operator; handled carelessly, it leaves a small but genuine scar in the historian that can confuse an investigation years later.
There is no fixed schedule. Leap seconds are announced in advance by the international timekeeping authority only when the difference between atomic time and the Earth's rotation grows large enough to justify one, which has historically meant roughly one every few years rather than on any regular calendar. Because they are irregular and rare, systems can run a long time without ever encountering one, which is part of why leap-second bugs stay hidden until they suddenly appear.
Leap smearing is a technique where a time source spreads the one-second correction across a window of several hours instead of applying it all at once. The clock runs a tiny fraction slow during that window so it absorbs the extra second smoothly, never stopping, repeating, or stepping backward. This keeps time strictly increasing, which avoids the duplicate and out-of-order timestamps that a sharp leap-second insertion can cause in historians and event logs.
Because a mishandled leap second can quietly corrupt the historical record. An inserted second can make a clock repeat or step backward, producing duplicate or misordered timestamps that break sequence-of-events analysis and can be mistaken for a real fault. Knowing how each time source handles the adjustment, and preferring sources that smear it, keeps the timeline clean through an event that only comes around every few years.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.