Addition and subtraction assignment operators

[HuaTsai]

Implement addition/subtraction assignment operators based on existing operators.
Resolves #2399

[HuaTsai]

CI problem in TestNodeGraph.

[fujitatomoya]

lgtm with green CI

[fujitatomoya]

CI:

• Linux
• Linux-aarch64
• Windows

[Ryanf55]

Any special handling needed for overflow/underflow?

[HuaTsai]

Hi @Ryanf55,
Sorry for forgetting to reply.
The overflow test is already in line 133 below.
For the underflow test, please check here: #2419 (comment).

Or let me paraphrase in another way:
I follow what happens when rclcpp::Duration + msg::Time.
It first becomes rclcpp::Duration + rclcpp::Time (implicit conversion).
During the conversion, negative seconds in msg::Time is not allowed.

rclcpp/rclcpp/src/rclcpp/time.cpp

Lines 52 to 54 in 99f0fc9

	if (seconds < 0) {
	throw std::runtime_error("cannot store a negative time point in rclcpp::Time");
	}

IMO this is a small design flaw since it does not match Unix that uses int32 to store time.
But in practice, who cares about time before 1970, so it should remain fine.
After that, positive int32 seconds and uint32 nanoseconds will generate positive int64 full nanoseconds.
A positive int64 nanoseconds add another int64 duration nanoseconds always not underflow.

That's my current understanding and therefore I do (and can) not test underflow.

[Ryanf55]

Is it written down anywhere that rclcpp::Time must use Unix time? I have used it in places to store time since boot, in the case that the embedded device does not have a RTC or network connection, and thus had no idea of any time except boot time. Certain unsafe uses of while loops, with timeouts and such can lead to weird bugs.

https://docs.ros2.org/beta3/api/rclcpp/classrclcpp_1_1Time.html

I agree, the likelyhood of underflow while using epoch time is low.

[HuaTsai]

Is it written down anywhere that rclcpp::Time must use Unix time?

I don't find such description, maybe my statement earlier is too biased.

I have used it in places to store time since boot, in the case that the embedded device does not have a

RTC or network connection, and thus had no idea of any time except boot time.
Yes, this reminds me that the clock source of rclcpp::Time could also be timestamps in rosbag.
Both of them are not using current epoch time.

[Ryanf55]

As long as overflow/overflow is tested somewhere, seems like a good approach to me.