LDATE, LTOD and LDT

Ed.3 Table 10 makes each a signed 64-bit count of nanoseconds; the range is the whole of it, as CODESYS, TwinCAT and PLCnext give it (decided 2026-11-08, florin; implementer choices). A date before 1970 is a negative count. A literal takes up to nine digits of a second; one that names no day or time, or that the type cannot hold, is refused (E0020).

At the edges

• An LTOD wraps at midnight, unflagged, as a TOD does.
• An LDT outside its range wraps and is flagged OVERFLOW, as a DT does; so does a difference outside LTIME.
• A long value made a short one drops what the short type is too coarse for, rounding down, unflagged: LDT_TO_DT the fraction of a second, LTOD_TO_TOD and LTIME_TO_TIME what is below a millisecond. Before 1970 down is earlier: LDT_TO_LDATE of the last nanosecond of 1969-12-31 is 1969-12-31.
• A long value the short type cannot hold gives the short type’s default value, flagged CONVERSION: an LDT before 1970 or after 2106-02-07 made a DT or DATE is 1970-01-01, an LTIME beyond ±24d20h31m23s647ms made a TIME is T#0s. The task goes on. Ed.3 Table 22 leaves this result to the implementer.
• DT, DATE, TOD and TIME widen to the long types without a conversion function (Ed.3 Figure 11), exactly. With one long operand the other is widened (Ed.3 6.6.1.6, rule 7): DT + LTIME is an LDT, never a DT, which could not hold the LTIME’s range.

SPLIT_LTOD and SPLIT_LDT give milliseconds, the rest dropped rounding down, as SPLIT_DT’s do (DATE, TOD and DT); the harness’s ldates case runs them, with the other conversions, tick by tick.