Refinement of Time.msg (2038, time scale, ...)

[i-and]

1. Is there a planned solution to problem 2038 (Time.msg is subject to year 2038 problems #85)? One of the possible solutions is a single field for storing ns of the int64 type.
2. Time scale.
   2.1 The comments on the Time type do not specify the time scale used. Maybe it should be clarified explicitly?
   2.2 Is UTC used for all timestamps in ROS2?
   2.3 If UTC is used, how is the situation correctly worked out when a corrective second occurs and in a situation when some nodes know about the fact of its occurrence and some do not? There will also be a non-linearity of the clock running.
   2.4 Has the option of using an International Atomic Time (TAI) timeline been considered for timestamps (PTP also uses TAI)?
3. Additional Info
   3.1 Synchronization Status. Time is often used for timestamps obtained based on global time. Maybe it makes sense to include in the Time type integral information about the synchronization status of the local clock at the moment of creating the timestamp?
   Variants of values:
   0 - undefined state of sync,
   1-there is synchronization with the Grandmaster with global clock (by GPS, NTP,....);
   2-synchronization service on the slave is stopped/error;
   3-there is no any synchronization (the slave does not receive synchronization events/messages);
   4-there is synchronization with the Grandmaster , which is not synchronized with the global clock (no GPS signal, no NTP server);
   ...

3.2 There can be extended diagnostics for the clock on the network. To logically link the diagnostics to the corresponding clock, you can consider adding a GUID or PTP Clock Identity (8 bytes) to the Time type.

[clalancette]

For issue 1 above, we have the open issue that you pointed out. One solution is indeed to switch to a single int64, though we haven't yet pursued that because it is a big change that will have a lot of repercussions to the downstream software.

I'd suggest opening two separate issues, one for the "Time scale" and one for the "Additional info". That way we don't have a redundant issue about the 2038 problem, and we can consider each of these issues separately.

Because of that, I'm going to go ahead and close this out. Thanks for bringing the issues up.

[i-and]

OK - #128 and #129