We were investigating if we should use ROS 2 Time or `std::chrono` for our product. Note that our use case is a highly safety critical real-time system influencing the priority of the arguments. Upon closer inspection, I found that ROS 2 Time is largely redundant to `std::chrono`. All functionality of ROS 2 simulated time can also be achieved by providing a custom `std::chrono` clock encapsulating the `rclcpp::Clock` which would look like this (modulo some shared ptr shenanigans I omitted): ``` struct ros2_clock { typedef std::chrono::nanoseconds duration; typedef duration::rep rep; typedef duration::period period; typedef std::chrono::time_point time_point; static constexpr bool is_steady = false; static time_point now() noexcept { return time_point(duration(clock.now().nanoseconds())); } static Clock clock; }; ``` So from my point of view it is hard to justify using ROS 2 Time as: 1. `rclcpp` uses `std::chrono::Duration` already. 2. `std::chrono` is safer as it is not possible to mix durations from different clocks. 3. `std::chrono` allows a custom time representation allowing to create overflow and underflow safe time operations. 4. With sticking to a single time library there is no confusion on which to use when and no performance degradation from type conversion. 5. `std::chrono` is the C++ standard many people are already familiar with. So given our use cases, are there arguments speaking for using ROS 2 Time in our code instead of `std::chrono`? --- [Visit Topic](https://discourse.ros.org/t/ros-2-time-vs-std-chrono/6293/1) or reply to this email to respond. If you do not want to receive messages from ros-users please use the unsubscribe link below. If you use the one above, you will stop all of ros-users from receiving updates. ______________________________________________________________________________ ros-users mailing list ros-users@lists.ros.org http://lists.ros.org/mailman/listinfo/ros-users Unsubscribe: