Fix OPC UA DT conversion from nanoseconds

[genishernandez]

Description

Fixes an issue where OPC UA DT values could be converted to
1970-01-01 instead of the actual DateTime.

Problem

When the OPC UA synchronization layer receives a DT value as an
integer Unix timestamp expressed in nanoseconds, the existing
conversion logic did not handle this representation.

As a result, the conversion fell back to:

1970-01-01 00:00:00+00:00

Root Cause

The DT conversion handled:

• (tv_sec, tv_nsec) tuples
• Python datetime objects

but did not handle integer nanosecond timestamps returned by some
OpenPLC debug interfaces.

Fix

Added support for integer Unix timestamps expressed in nanoseconds:

datetime.fromtimestamp(
    value / 1_000_000_000,
    tz=timezone.utc
)

[genishernandez]

The issue was detected while testing OPC UA DateTime (DT) variables in OpenPLC Runtime on an Ubuntu Linux virtual machine.

During testing, the OPC UA DT value was being interpreted as 1970-01-01 instead of the current date.

We traced the issue to the value representation returned by the OpenPLC debug interface. In this case, the DT value was provided as an integer Unix timestamp expressed in nanoseconds, while the existing conversion logic only handled (tv_sec, tv_nsec) tuples and Python datetime objects.

The conversion was updated to support integer nanosecond timestamps.

The fix was verified using the current timestamp:

Input:
1788717976960499968

Result:
2026-09-06 18:06:16.960500+00:00

The result matched the expected current UTC time.