Can ROS timers be safe to clock jumps?
Ubuntu 20.04, ROS noetic
It seems that ROS timers are not completely robust to clock jumps e.g. from daylight time savings.
I created a ros::WallTimer that triggered every second and logged the intervals with a std::chrono::steady_clock. Then I set back the clock 1 hour and then again 1 hour forward.
I get this output:
[ WARN] [1643816822.911882384] [/node]: tick 1.0
[ WARN] [1643816823.911713294] [/node]: tick 2.0
[ WARN] [1643816824.911731140] [/node]: tick 3.0
[ WARN] [1643816825.911736092] [/node]: tick 4.0
[ WARN] [1643816826.911609692] [/node]: tick 5.0
[ WARN] [1643813221.572964459] [/node]: tick 7.0 // lost timer tick after setting clock -1 hour
[ WARN] [1643813222.572882079] [/node]: tick 8.0
[ WARN] [1643813223.572958188] [/node]: tick 9.0
[ WARN] [1643813224.572914005] [/node]: tick 10.0
[ WARN] [1643816820.668951557] [/node]: tick 11.0 // extra timer tick after setting clock +1 hour
[ WARN] [1643816820.669097722] [/node]: tick 11.0
[ WARN] [1643816821.669390752] [/node]: tick 12.0
[ WARN] [1643816822.669412872] [/node]: tick 13.0
Does ROS1 have any ways to prevent these irregularities? Among other things I am concerned it affects certain heartbeat intervals in my system.
[EDIT] I notice that Ubuntu resets the clock seconds when I shift the hour:
Wed 02 Feb 2022 05:19:13 PM CET
Wed 02 Feb 2022 04:19:00 PM CET
... so this might explain some of the above. However it does not change the underlying problem: Does a steady timer exist in ROS1?