TIME producer does not correct provided timestamp

[mrrosen]

The documentation on transmit suggests the provided timestamp should be a UNIX timestamp, so have Epoch Jan 1 1970 UTC. However, the function does not correctly offset the provided timestamp as it does with the one produced internally if no timestamp is provided (https://canopen.readthedocs.io/en/latest/_modules/canopen/timestamp.html#TimeProducer.transmit).

Either the documentation should be fixed to say the provided timestamp should use the CANopen epoch or the line correcting the timestamp should be fixed to respect Python operator precedence:

delta = (timestamp or time.time()) - OFFSET

[sveinse]

Unless I'm completely mistaken, the order of precedence is preserved in both variants:

# These are equivalent
delta = timestamp or time.time() - OFFSET
delta = (timestamp or time.time()) - OFFSET

When the provided timestamp is based on epoch 1970, OFFSET needs to be subtracted to get it to canopen January 1, 1984 epoch.

[mrrosen]

Unless I'm completely mistaken, the order of precedence is preserved in both variants:

# These are equivalent
delta = timestamp or time.time() - OFFSET
delta = (timestamp or time.time()) - OFFSET

When the provided timestamp is based on epoch 1970, OFFSET needs to be subtracted to get it to canopen January 1, 1984 epoch.

These expressions are not the same, - comes before or in operator precedence: https://docs.python.org/3/reference/expressions.html#operator-precedence

Correct that OFFSET should be subtracted from either timestamp argument or time.time() for a time in CANopen epoch, but the current expression doesn't do that.

[sveinse]

Yeah, I see it now

>>> 0 or 1 - 5
-4
>>> (0 or 1) - 5
-4
>>> None or 1 - 5
-4
>>> (None or 1) - 5
-4
>>> 1 or 2 - 5
1
>>> (1 or 2) - 5
-4