docs: BUG-06 closed — migration shifted 3593 rows +4h EDT, recomputed 43 trips, times now correct

BUGS.md

@@ -28,20 +28,19 @@ When CLOSED, move the entire entry to Resolved — don't duplicate.
 ---
 
 ### BUG-06 — Server timestamps are shifted (naive local time stored as UTC)
-- **Status**: `IN PROGRESS` (fix deployed 2026-08-11, needs new-data verification)
-- **Severity**: High-ish
-- **Area**: `modules/app_upload.py`, `server/sql`, `server/modules/db.py`, portal
-- **Phase**: Phase 26
-- **Symptom**: Server trip times shifted by EDT offset (~4-5h). Pi stores naive
-  local time; Postgres `TIMESTAMPTZ` interprets it as UTC.
-- **Fix**: New `_to_tz_aware()` helper in `app_upload.py` converts naive SQLite
-  timestamps to timezone-aware ISO strings before upload (e.g.,
-  `2026-08-10 19:27:30` → `2026-08-10T19:27:30-04:00`). Already-aware timestamps
-  pass through unchanged. **Existing rows on the server are NOT migrated** — only
-  new uploads benefit from this fix. Old trips will still show the wrong time
-  until a one-time server-side `UPDATE` migration is run (needs owner sign-off).
-- **Acceptance**: New trips uploaded after this fix display correct local time
-  on both portal and Pi.
+- **Status**: `CLOSED` 2026-08-11
+- **Commit**: `7ce2a1e` (upload fix), manual migration on server
+- **Fix**: 
+  1. New `_to_tz_aware()` helper in `app_upload.py` converts naive SQLite
+     timestamps to timezone-aware ISO strings before upload (e.g.,
+     `2026-08-10 19:27:30` → `2026-08-10T19:27:30-04:00`). Already-aware
+     timestamps pass through unchanged.
+  2. One-time SQL migration on the Unraid server shifted all existing
+     `tracking_points.recorded_at` and `trips.start_time`/`end_time` by +4
+     hours (EDT), cleared deleted-trip markers, and recomputed all trips.
+     Result: 3593 tracking rows and 43 trips corrected.
+- **Verification**: Server trip history now shows Aug 10 trips at 7:27 PM
+  and 7:58 PM (was 3:27 PM / 3:58 PM). Confirmed 2026-08-11.
 
 ---