Skip to content

Report the PAS log timestamp as recorded, not as UTC - #191

Merged
abrignoni merged 1 commit into
mainfrom
fix/pas-log-local-clock
Sep 7, 2026
Merged

abrignoni merged 1 commit into
mainfrom
fix/pas-log-local-clock

Conversation

@abrignoni

Copy link
Copy Markdown
Owner

Reports the PAS log timestamp as recorded rather than as UTC.

The log writes the head unit's local clock and states no zone on the line. The column was typed datetime and stamped UTC, so every row was placed 4 hours before it happened.

  • Measured 4 hours behind UTC on 405 of 412 comparisons against the UTC the log publishes on its own lines.
  • A Sync Gen3 extraction checked against received GPS UTC gives 4 hours on 38 of 51 pairs, 5 on 4 and 6 on 7, so the offset varies and cannot be assumed.
  • Dropping the tzinfo alone would not fix it, since lavafuncs coerces a naive datetime to UTC.

Row counts are unchanged and Timestamp is the only column that moves. The notes name the VS_CLOCK_QUEUE lines that record the offset. Baselines re-recorded and shown to fail against the previous behaviour.

🤖 Generated with Claude Code

The pas_debug log writes the head unit's own clock and records no zone on the
line. The module typed that value as a datetime and stamped it UTC, so the
report, the timeline and the LAVA database all read it as a UTC instant.

It is not one. The log publishes UTC on its own lines, and comparing the two
gives 4 hours behind UTC on 405 of 412 comparisons in the committed Sync 4
case, the other 7 differing by a minute because the published value carries no
seconds. A Sync Gen3 extraction checked the same way against the GPS UTC it
receives gives 4 hours on 38 of 51 pairs, 5 hours on 4 and 6 hours on 7, so the
offset is not constant and cannot be assumed. Every Dev Loc row was therefore
being placed 4 hours before it happened.

Dropping the tzinfo alone would not have fixed it: lavafuncs coerces a naive
datetime to UTC, so the same wrong instant would have been stored with nothing
in the artifact to show it. The column is no longer declared a datetime, so the
reading is carried as recorded and no instant is asserted. The KML and timeline
key on the header name, not the type, and both still carry the value.

Row counts are unchanged on every artifact and the only column that moves is
Timestamp. Sub-second precision now survives, which the epoch integer dropped.
The notes say what the value is and name the VS_CLOCK_QUEUE lines that record
the offset, so an examiner can establish it per extraction. Baselines re-recorded
and shown to fail against the previous behaviour.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@abrignoni
abrignoni merged commit 6a188c2 into main Sep 7, 2026
10 checks passed
@abrignoni
abrignoni deleted the fix/pas-log-local-clock branch September 10, 2026 03:29
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.

1 participant