Questions
0
Answered
DDS Time_t origin, range?
The RTI DDS documentation for Time_t simply states that it represents "a moment in time". It doesn't document an origin or range. What is the origin and range for this field? I ask because I want to know when it will rollover, and how to convert to/from Linux seconds-from-the-epoch.
The constructor takes an int seconds, and Java defines the default int to be signed 32 bits. From a quick calculation, that number will overflow in about 68 years from the origin.
Any idea what the origin for DDS Time_t is?
Thanks,
Brad
The constructor takes an int seconds, and Java defines the default int to be signed 32 bits. From a quick calculation, that number will overflow in about 68 years from the origin.
Any idea what the origin for DDS Time_t is?
Thanks,
Brad
Customer support service by UserEcho
To the best of my knowledge it's similar to POSIX struct timespec. So you're absolutely correct that the signed 32 bits since the UNIX epoch means it inherits the year 2038 problem. For Time_t as it is used by DDS (mainly in SampleInfo) a monotonic clock might eventually be preferable; although it could be confusing that "Time_t" encodes only a counter if configured that way. A discussion of monotonic versus realtime clock usage appears in RTI's documentation. The availability of the monotonic clock is platform-specific
The Time_t defined in ice.idl (used in device_time and presentation_time) could be changed at the "OpenICE" level. We could easily convert the seconds component to a 'long long' 64-bit value in a later version of OpenICE for the benefit of our descendants in 2038. I think this makes sense. What do you think?
Thank you
Jeff