I don't see any means how to combine these two.

This is what I would do to convert between the types:

When converting a builtin_interfaces/Time to a rcl_time_point_t:
- Ensure the Time.sec is not negative, otherwise raise an error that we cannot represent time points before the unix epoch
When converting a rcl_time_point_t to a builtin_interfaces/Time:
- Ensure the time point value does not exceed a 32-bit seconds component (otherwise raise an error)

Is that not sufficient?

Now, I personally advocate for changing the msg to be uint32 as well for seconds.

Personally I'd rather simplify it to just a single uint64 of nanoseconds, but doing that or what you suggested would be pretty disruptive to porting ROS 1 code. I still think it may be worth it.

My reasoning here is that I don't understand what a negative timestamp should mean.

It's never stated explicitly, but in ROS 1 the value in a Time object or message is almost always referencing the Unix epoch. So I guess a negative value would be a time before 1970.

Also, with that in mind, what's the difference in Time.sec = 0 and Time.sec = now() then?

What? Time has sec and nanosec, I don't know what Time.sec = now() would do, and I guess it would be different from Time.sec = 0 because now() would presumably not always return 0? I have no clue what you're getting at with this question.

A second problem I see with the current format is how to specify a negative time of -0.5 sec. Only the sec field has the chance of becoming negative, yet -0,+0 is going to be the same value.

As @mikaelarguedas explained, you can represent -0.5 seconds with a -1, 500000000 pair because you would add -1 and 500000000 / 1e9 (0.5) to get -0.5.

I'm not familiar with the rationale that led to the definition of Time and time_point in the first place so I cannot really give an opinion to the first questions.

The rationale for the rcl_time_point_t being a single uint64_t of nanoseconds was described here:

https://discourse.ros.org/t/of-clocks-and-simulation-betimes-and-otherwise/1587/7

The reason for ROS 1's time layout is not as clear, but it was probably coping Linux's timespec type (https://linux.die.net/man/3/clock_gettime).

As long as there is a way to have a different time reference a negative value on that scale could (at least theoretically) exist isn't it ?

If I understand what you're saying here (that there could be different reference points and because of that there could be negative values), then I would say first that there should not be different time references if there is no field in the message to indicate which one. If you don't agree on a common (assumed) time point reference (like the unix epoch) then you cannot know what reference a given time point is associated with because there is no context with the data. To allow that we would have to have a field with each time point that indicated its reference point (i.e. one for unix epoch, one for Window's time point which is sometime in 1600 AD, etc...).

Regardless of whether or not we have a common reference you can have negative time point values. They would simply mean "a point in time before the reference point". But the chance for having those is orthogonal to whether or not we have a common agreed upon time point reference.

It looks like time_point assumes epoch time.

If you mean the rcl_time_point_t, then yes it does.

I'm don't think that the Time message assumes any reference

It's not explicitly stated, but for "WallTime" in ROS 1, it is the unix epoch:

http://docs.ros.org/latest/api/rostime/html/src_2time_8cpp_source.html#l00102

rclcpp::Time operators #352

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions