Thanks to visit codestin.com
Credit goes to github.com

Skip to content

TIME producer does not correct provided timestamp #563

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
mrrosen opened this issue Feb 25, 2025 · 3 comments · May be fixed by #576
Open

TIME producer does not correct provided timestamp #563

mrrosen opened this issue Feb 25, 2025 · 3 comments · May be fixed by #576
Labels

Comments

@mrrosen
Copy link

mrrosen commented Feb 25, 2025

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
Copy link
Collaborator

sveinse commented Apr 26, 2025

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
Copy link
Author

mrrosen commented Apr 26, 2025

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
Copy link
Collaborator

sveinse commented Apr 26, 2025

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

@sveinse sveinse linked a pull request Apr 26, 2025 that will close this issue
@sveinse sveinse added the bug label Apr 26, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants