Preparing Connext Applications for the Year 2038 Transition

Submitted by avira on Wed, 05/13/2026 - 14:14

Beginning with RTI Connext DDS 7.2.0, RTI added support for operating beyond the Year 2038 time rollover issue. Systems running Connext DDS 7.2.0 or later can operate correctly through the year 2106.

What Changed?

To address the Year 2038 limitation, RTI updated how time values are represented:

  • DDS_Time_t seconds were expanded from a 32-bit integer to a 64-bit integer

  • RTPS_Time_t seconds (used on the wire) were updated to align with the OMG RTPS specification

These updates are standards-compliant and interoperable with other DDS vendors implementing the RTPS specification version 2.3 or later.

 Impact

Most applications upgrading from a release prior to 7.2.0, to any release after that, will require little or no modification. However, customers may notice:

  • Compiler warnings or small code updates where Time_t values are directly manipulated

  • Changes to Secure DDS logging topic names:

    • BuiltinLoggingType → BuiltinLoggingTypeV2

Applications consuming secure logging data may need updates to support the new logging topic type.

 Why Older Versions Are at Risk

Applications using Connext DDS releases older than 7.2.0 may experience serious issues after January 2038 if they rely on the system clock, including:

  • Communication failures

  • Discovery and liveliness problems

  • Missed heartbeats and data repair failures

  • CPU spikes or stalled event processing

  • DestinationOrder QoS timestamp issues

These behaviors occur because older releases depended on signed 32-bit system-clock time internally.

 Recommended Action

RTI strongly recommends upgrading to the latest Connext DDS 7.3.1.x  or later release.

For customers who cannot upgrade before 2038, in order for their system to continue to operate past 2038, they must configure both the internal and external DDS clocks to use the monotonic clock where supported (see Platform Support below).

Example XML configuration:

<participant_qos>

   <property>

       <value>

           <element>

               <name>dds.clock.external_clock</name>

               <value>monotonic</value>

           </element>

           <element>

               <name>dds.clock.internal_clock</name>

               <value>monotonic</value>

           </element>

       </value>

   </property>

</participant_qos>

Using monotonic clocks prevents rollover-related failures, because monotonic clocks continuously increase from system startup and are not tied to wall-clock time.

 Important Consideration

When the external clock is configured to use a monotonic clock:

  • DestinationOrder::BY_SOURCE_TIMESTAMP is no longer a valid configuration option because a timestamp from a monotonic clock on one machine has no relation to a monotonic clock timestamp on another.

  • It is up to the user to review where source timestamps are being used in their applications to determine if that usage is still meaningful when using the monotonic clock.

 Platform Support

Monotonic clock support is available on major supported platforms including:

  • Linux

  • Windows

  • QNX

  • VxWorks

Customers should verify support in their release-specific platform notes.

 
Product:
Platform:
Programming Language:
Keywords: