I think this will diverge from how DDS specifies duration_t. We should carefully consider the consequences,

Imo it would be even better to keep it as unsigned and once .idl will allow us to specify that also constrain the upper limit to < 1 000 000 000.

Changing it to signed isn't a good idea imo. You can't really compare it to the rcl time point duration because it's a single nanoseconds value, not part of a nanoseconds/seconds pair.

If we were to change this at all I'd advocate for a single nanoseconds signed 64-bit integer, but that would probably be too disruptive (different argument and out of scope for this issue at least).

I don't think we should compare to how DDS does it, since they're probably going to change their seconds component to unsigned to avoid the 2038 problem. They won't change anything for 2038 with respect to durations, only time points.

Either way I wouldn't make the change proposed here.

Err, I thought we were talking about a time point not a duration, so never mind the part about 2038 problem.

I still would leave this with an unsigned nanoseconds, though I could possibly be swayed if we could enforce the boundary on it that it's within [0, 1e9).

I think the comparison to DDS is valuable. Not necessarily as in "follow what they do" but "consider why they chose what they did. The upper bound ensures that a duration message is automatically "nomalized" which I think is a good thing.

The upper bound ensures that a duration message is automatically "nomalized" which I think is a good thing.

Well, signed or unsigned doesn't change the boundary issue. It just means you need two boundaries or just one. Whereas having signed nanoseconds avoids mixing unsigned and signed arithmetic.

The other thing to consider for consistency is the same semantic as ROS1. If we're going to break that consistency there's not much reason to keep it in two fields. The 64bit signed nanoseconds is much simpler to process. But for now I'd suggest keeping it as is.

Ignoring the signed/unsigned mixing for the moment, if the duration message is signed sec and unsigned nanosec, then what is the length of time indicated by .sec = -1, .nanosec=500000000?

what is the length of time indicated by .sec = -1, .nanosec=500000000

- 500 000 000 ns

Thanks for the explanation.