Skip to content

blf: interpret object timestamps as signed 64-bit values - #2101

Open
FlorianMickler wants to merge 1 commit into
hardbyte:mainfrom
FlorianMickler:blf_fix_prerecord_timestamps
Open

blf: interpret object timestamps as signed 64-bit values#2101
FlorianMickler wants to merge 1 commit into
hardbyte:mainfrom
FlorianMickler:blf_fix_prerecord_timestamps

Conversation

@FlorianMickler

Copy link
Copy Markdown

Change BLF object header timestamp fields from uint64 (Q) to int64 (q) for both V1 and V2 object headers.

Observed CANape-generated BLF files containing messages before the recording start timestamp. When interpreted as unsigned values, these timestamps wrap around and appear approximately 2^64 ns in the future, resulting in invalid timestamps (e.g. year 2611) and NaT values in pandas.

Using signed 64-bit timestamps correctly preserves negative recording-relative offsets while still providing a usable range of approximately ±292 years at nanosecond resolution.

Root cause:
 
A timestamp of -60 s was decoded as
 
2^64 ns - 60 s
 
which produced timestamps approximately 584 years in the future. The resulting values exceeded the valid pandas datetime range and appeared as NaT.

Summary of Changes

this fixes a bug observed with pre-recording buffers in some CANape blf recordings.

Related Issues / Pull Requests

no issue opened.

  • Closes #
  • Related to #

Type of Change

  • [ X ] Bug fix
  • New feature
  • Documentation update
  • Refactoring
  • Other (please describe):

Checklist

  • I have followed the contribution guide.
  • I have added or updated tests as appropriate.
  • I have added or updated documentation as appropriate.
  • I have added a news fragment for towncrier.
  • All checks and tests pass (tox). (blf related ones: )
    PASS [ 4.004ms] test/logformats_test.py::TestBlfFileFormat::test_append_mode
    PASS [ 877.1us] test/logformats_test.py::TestBlfFileFormat::test_can_error_frame_ext
    PASS [ 1.020ms] test/logformats_test.py::TestBlfFileFormat::test_can_fd_message
    PASS [ 828.9us] test/logformats_test.py::TestBlfFileFormat::test_can_fd_message_64
    PASS [ 838.3us] test/logformats_test.py::TestBlfFileFormat::test_can_message
    PASS [ 721.1us] test/logformats_test.py::TestBlfFileFormat::test_can_message_2
    PASS [ 2.659ms] test/logformats_test.py::TestBlfFileFormat::test_file_like_context_manager
    PASS [ 2.611ms] test/logformats_test.py::TestBlfFileFormat::test_file_like_explicit_stop
    PASS [ 651.6us] test/logformats_test.py::TestBlfFileFormat::test_issue_1905
    PASS [ 2.605ms] test/logformats_test.py::TestBlfFileFormat::test_path_like_context_manager
    PASS [ 2.172ms] test/logformats_test.py::TestBlfFileFormat::test_path_like_explicit_stop
    PASS [ 355.9us] test/logformats_test.py::TestBlfFileFormat::test_timestamp_to_systemtime

Additional Notes

Change BLF object header timestamp fields from uint64 (Q)
to int64 (q) for both V1 and V2 object headers.

Observed CANape-generated BLF files containing messages
before the recording start timestamp. When interpreted as
unsigned values, these timestamps wrap around and appear
approximately 2^64 ns in the future, resulting in invalid
timestamps (e.g. year 2611) and NaT values in pandas.

Using signed 64-bit timestamps correctly preserves negative
recording-relative offsets while still providing a usable
range of approximately ±292 years at nanosecond resolution.

Root cause:
 
A timestamp of -60 s was decoded as
 
	2^64 ns - 60 s
 
which produced timestamps approximately 584 years in the
future. The resulting values exceeded the valid pandas
datetime range and appeared as NaT.
@mergify

mergify Bot commented Sep 9, 2026

Copy link
Copy Markdown
Contributor

Tick the box to add this pull request to the merge queue (same as @mergifyio queue).

  • Queue this pull request

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants