read_blastware_file built ev.timestamp from footer ts1, which for a WAVEFORM is
the monitoring-session start (a unit arming at 06:00 stamps 06:00 on every event
that day) — so every waveform's time was hours off (vomit-list #3, "~4.5 h off").
The event time is footer ts2 (the recording stop); BW's displayed Date/Time is
the trigger = ts2 - record duration.
Root cause proven against the BE12844 oracle set: 5 of 7 events decoded to the
identical 06:00:13 (the shared session start); ts2 gives distinct plausible
event times (N844LQHB ts2 = 10:33:32, BW trigger 10:33:29 = ts2 - 3.0 s rectime).
* read_blastware_file now uses ts2 for waveforms (discriminated by which codec
decoded the body, not the filename — save_imported_bw passes a tmp name).
Histograms keep ts1 (the ~24 h window start, which IS the event time).
* Binary-only decode can't get the exact trigger: the STRT record-time byte is
a misparsed record-type marker (0x46=70), so ts2 (the stop, ~record duration
after the trigger) is the best estimate. A paired BW report carries the exact
trigger — apply_report_to_event now overlays event.timestamp from
report.event_datetime, matching the existing build-path override (line ~441).
Tests: waveform → ts2, histogram → ts1 unchanged, report → exact trigger.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01YDXjZCr4RqT2U3QvMDhgzf
serversdownandClaude Opus 4.8
a84a46e9d4