PLC timestamp unit conversion for factory displays

Define what the timestamp represents

A timestamp needs more than a data type. Its meaning depends on four things:

• Epoch: the date and time from which the count starts.
• Unit: seconds, milliseconds, microseconds, nanoseconds, or another interval.
• Range and signedness: which dates the stored number can represent.
• Time convention: whether the value represents a UTC instant or local calendar time.

An integer tag does not necessarily communicate all of this information. A name such as EventTime leaves too much unstated. A name such as EventEpochSeconds, backed by documentation specifying the epoch and UTC convention, makes the interface easier to maintain.

Do not assume every long date-and-time type uses the same representation. Confirm the controller's documented timestamp format and the documented result of its conversion operation. Converting a date-and-time value is not necessarily the same as reading its underlying storage as an integer.

Also distinguish the recorded event time from the current controller clock. A popup for a saved event must use the time captured with that event, not the time at which the display reads it.

Why nanoseconds can turn into a date decades later

For a source explicitly defined as elapsed nanoseconds since 1970-01-01 00:00:00 UTC, the relationship is:

whole elapsed seconds = elapsed nanoseconds / 1000000000

One second therefore has a raw count of 1000000000. A formatter expecting elapsed seconds needs 1 for that same instant.

If the formatter instead interprets 1000000000 as seconds since that epoch, it reaches September 2001 rather than the beginning of January 1970. The calendar result can look reasonable even though the scale is wrong.

For nonnegative integer counts, integer division retains whole seconds and discards the fractional remainder. For example:

The remainder matters when two events occur within the same second. Once it has been discarded, a seconds formatter cannot reconstruct it.

Byte swapping is not a unit conversion. If both ends show the same decimal value, swapping bytes changes that value rather than correcting its scale. Investigate byte order only when the numeric transfer itself is wrong and the protocol or driver documentation supports that diagnosis.

Follow the event value through OPC UA

Trace one known event through the complete path. Record the raw value and its intended meaning at each boundary, rather than comparing only the final calendar text.

If the PLC publishes 1 but the display receives something else, investigate the binding, type conversion and communication status. If both show 1 but the popup is wrong, look at its expression and formatting rules. If both show 1000000000 for the one-second example, the unit conversion has not reached the displayed path.

An OPC UA integer value carrying an application timestamp is not automatically an OPC UA DateTime. The latter has its own defined encoding: intervals of 100 nanoseconds from an epoch in 1601. Do not apply the nanoseconds-since-1970 calculation to it without an explicit conversion.

Also keep the tag's value separate from OPC UA source and server timestamps. Those metadata timestamps describe timing associated with the data value; they are not automatically the saved event time carried inside it.

A saved event timestamp may correctly remain unchanged between events. When the problem is freshness rather than arithmetic, diagnosing factory screen update delay addresses the separate update path.

Divide before narrowing the value

The order of operations determines whether the conversion preserves useful information.

An unsigned 32-bit integer holds values from 0 through 4294967295, based on its 32-bit width. That range can hold billions of elapsed seconds, but only a little over four seconds when the same integer is interpreted as nanoseconds.

Casting a full nanosecond count into that destination before division can therefore cause overflow, rejection or loss of high-order information, depending on the conversion rules. Dividing the damaged result cannot restore the original timestamp.

Keep the source count in a sufficiently wide integer representation throughout the division. Make sure the divisor and intermediate expressions also use suitable types. Then check the whole-seconds result before assigning it to the published destination.

A type named UDINT or ULONG is not enough evidence that every stage supports the required dates. Confirm the width and signedness in each installed environment. A downstream expression or date formatter may accept a smaller range than the tag holding its input.

For a destination that cannot represent negative values, reject or flag pre-epoch timestamps rather than allowing an unsigned conversion to turn them into large positive numbers. Define how invalid or out-of-range values appear in the popup. Do not silently substitute zero, which can look like a legitimate epoch timestamp.

Choose the precision the event needs

Whole seconds are suitable when the display only needs a readable event time and subsecond distinctions have no operational value. They are not suitable when the display must distinguish closely spaced events.

Avoid using ordinary floating-point arithmetic as a shortcut without checking precision. A binary64 floating-point value has 53 bits of integer precision. Large nanosecond counts can exceed that exact-integer range, so converting them to floating point can lose low-order digits before formatting begins.

If you publish seconds and remaining nanoseconds separately, capture them from the same saved timestamp. Use a coherent snapshot or a documented consistency mechanism so the display cannot combine seconds from one event with a fraction from another. The same issue applies to separate year, month, day and time tags.

Timestamp precision alone does not establish unique event identity. Two events can share a timestamp because of clock resolution or capture behavior. Retain a separate event identifier when the application needs reliable identity.

Separate clock display from unit conversion

Correct scaling establishes the elapsed time count. It does not choose the displayed time zone or establish that the controller clock was accurate when the event occurred.

First compare the expected instant and the converted numeric value using a documented UTC convention. Then check the popup's local-time conversion and formatting settings. A whole-hour difference often points toward time-zone handling, but it is not proof by itself.

Avoid applying a fixed hour offset as an arithmetic repair. Local offsets can change with daylight-saving rules, and different parts of the system may already apply the conversion. Keep a clear boundary between the stored instant and its presentation.

When local calendar fields are transferred without a UTC offset, repeated local times during a clock change can be ambiguous. Decide whether that ambiguity is acceptable before choosing calendar fields as the interface.

Check the complete display path

Use an isolated diagnostic record or test environment rather than overwriting production event history. Check a known whole-second value, a value with a fractional part, and dates near the limits your application actually requires.

The one-second example should produce 1 at the input to a seconds-based formatter. The fractional example should either retain its remainder or discard it deliberately, according to the interface specification. Invalid values should produce a clear invalid indication rather than a plausible date.

Finally, confirm that the popup still references the converted tag after configuration changes. Correct PLC arithmetic does not help if the expression continues reading the original nanosecond value. A successful check follows the same saved event from its source record through the published value to the final text.

Questions