Skip to content

Improve set_time error handling for large Python integers #9839

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.

Sign up for GitHub

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

Merged
merged 2 commits into from
Apr 30, 2025
Merged

Improve set_time error handling for large Python integers #9839

Changes from 1 commit
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
c4da1e6
Warn when timestamp value is out of range
oxkitsune Apr 29, 2025
f354549
Simplify check
oxkitsune Apr 29, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
17 changes: 12 additions & 5 deletions rerun_py/rerun_sdk/rerun/time.py
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -101,11 +101,18 @@ def set_time(
)
elif timestamp is not None:
nanos = to_nanos_since_epoch(timestamp)
bindings.set_time_timestamp_nanos_since_epoch(
timeline,
nanos,
recording=recording.to_native() if recording is not None else None,
)
try:
bindings.set_time_timestamp_nanos_since_epoch(
timeline,
nanos,
recording=recording.to_native() if recording is not None else None,
)
except OverflowError as err:
raise ValueError(
f"set_time: `timestamp={timestamp!r}` is out of range; "
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What is the !r?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It formats the value using repr(), instead of str().

import numpy as np

a = np.int64(123)
b = 123

print(f"{a!r} {a}")
print(f"{b!r} {b}")

would result in:

np.int64(123) 123
123 123

Figured that this would be desired to clearly show which type is being used, since we can take in numpy integers, python integers and floats iirc.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

TIL!

f"expected seconds since Unix epoch, datetime.datetime, or numpy.datetime64 "
f"(timeline='{timeline}')"
) from err
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How large integers were you passing in, and why?

And shouldn't we protect against the same problem for sequence and duration timelines too?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was passing a timestamp in milliseconds since unix epoch, e.g. '1_745_943_196_000'. But since we assume seconds, it would then be multiplied by 1e9 to convert to nanoseconds.

I don't think sequence and duration suffer from the same gotcha, so I'd argue it's not necessary.

Copy link
Member

@emilk emilk Apr 29, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds like we could improve the error message then with something along the lines of:

if 1_500_000_000_000 < timestamp < 2_000_000_000_000:
    raise "Expected seconds since unix epoch, but it looks like this is milliseconds"

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yea I like this more as well. However 2_000_000_000_000 is only valid for about 8 years.

Let's check if timestamp is bigger than 1e11 which will always mean milliseconds instead of seconds 👍



def to_nanos(duration: int | np.integer | float | np.float64 | timedelta | np.timedelta64) -> int:
Expand Down
Loading