Revision history [back]

I expect DST time jumps are not time jumps at all because unix epoch time keeps marching forward behind the scenes regardless, and not at all the same as changing your system clock.

Why not use use std::chrono steady_clock as a timer when it matters? There's probably a not-ros C++ example of how to trigger a steady callback.

There could be a use case where a system is going to be disconnected from the internet for such a long time a backwards time jump could happen (https://serverfault.com/questions/94683/will-ntp-drift-the-clock-backwards), and a ros system needs to be running at the same time the re-connection happens, and if the timer isn't steady something bad happens?

(The std::chrono steady clock vs. system clock issue: https://stackoverflow.com/questions/31552193/difference-between-steady-clock-vs-system-clock)

(https://askubuntu.com/questions/521171/time-keeps-changing-between-bios-windows-7-ubuntu-14-04 is sort of related, maybe isn't a problem with modern Windows)

There are a lot of issues with nodes and timers not handling the non-wall ros clock jumping backwards in time which happens if you are looping playback of a ros bag: some stop functioning entirely, others report errors and recover- that kind of clock time jumping ought to be more of a first class feature, more ought to be done to test for that or make it much less likely a given node or library call implementer handles those jumps the wrong way.

Some ros2 std chrono steady clock discussion: https://discourse.ros.org/t/ros-2-time-vs-std-chrono/6293/9

I expect DST time jumps are not really time jumps at all because unix epoch time keeps marching forward behind the scenes regardless, and not at all the same as changing your system clock.

Why not use use std::chrono steady_clock as a timer when it matters? There's probably a not-ros C++ example of how to trigger a steady callback.

There could be a use case where a system is going to be disconnected from the internet for such a long time a backwards time jump could happen (https://serverfault.com/questions/94683/will-ntp-drift-the-clock-backwards), and a ros system needs to be running at the same time the re-connection happens, and if the timer isn't steady something bad happens?

(The std::chrono steady clock vs. system clock issue: https://stackoverflow.com/questions/31552193/difference-between-steady-clock-vs-system-clock)

(https://askubuntu.com/questions/521171/time-keeps-changing-between-bios-windows-7-ubuntu-14-04 is sort of related, maybe isn't a problem with modern Windows)

There are a lot of issues with nodes and timers not handling the non-wall ros clock jumping backwards in time which happens if you are looping playback of a ros bag: some stop functioning entirely, others report errors and recover- that kind of clock time jumping ought to be more of a first class feature, more ought to be done to test for that or make it much less likely a given node or library call implementer handles those jumps the wrong way.

Some ros2 std chrono steady clock discussion: https://discourse.ros.org/t/ros-2-time-vs-std-chrono/6293/9

I expect DST time jumps are not really time jumps because unix epoch time keeps marching forward behind the scenes regardless, and not at all the same as changing your system clock.

Why not use use std::chrono steady_clock as a timer when it matters? There's probably a not-ros C++ example of how to trigger a steady callback.

There could be a use case where a system is going to be disconnected from the internet for such a long time a backwards time jump could happen (https://serverfault.com/questions/94683/will-ntp-drift-the-clock-backwards), and a ros system needs to be running at the same time the re-connection happens, and if the timer isn't steady something bad happens?

(The std::chrono steady clock vs. system clock issue: https://stackoverflow.com/questions/31552193/difference-between-steady-clock-vs-system-clock)

(https://askubuntu.com/questions/521171/time-keeps-changing-between-bios-windows-7-ubuntu-14-04 is sort of related, maybe isn't a problem with modern Windows)

There are a lot of issues with nodes and timers not handling the non-wall ros clock jumping backwards in time which happens if you are looping playback of a ros bag: some stop functioning entirely, others report errors and recover- that kind of clock time jumping ought to be more of a first class feature, more ought to be done to test for that or make it much less likely a given node or library call implementer handles those jumps the wrong way.

Some ros2 std chrono steady clock discussion: discussion + plus simulation time and non 1:1 time: https://discourse.ros.org/t/ros-2-time-vs-std-chrono/6293/9