From b1d78fdda7e04ab9228dcbf48f3fddb06ecb9027 Mon Sep 17 00:00:00 2001 From: mrramam Date: Sun, 13 Sep 2026 15:47:48 -0700 Subject: [PATCH] fix(devices): emit stored timestamps as explicit UTC instants MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The Devices tab showed Last Updated about seven hours ahead of the truth in US/Pacific. SQLite's CURRENT_TIMESTAMP is always UTC and ignores TZ, and it writes "YYYY-MM-DD HH:MM:SS" with no zone marker. V8 reads a space-separated, offset-less timestamp as local time, so every consumer landed an offset away from the stored instant. The digits look plausible, which is why it survived. Container and host timezone configuration cannot fix this; the backend already has the correct TZ and still writes UTC, as specified. Timestamps now become ISO-8601 with an explicit Z at the API boundary, through one helper, rather than each caller knowing the storage convention. Storage is unchanged, so no migration and no mixed formats in ORDER BY. Three consumers were reading the ambiguous form: - GET /api/devices — the Last Updated column, the reported symptom. - getDeviceUpdateTimeMs — feeds the Last-Modified header on three device endpoints, which advertised a time in the future west of UTC. ETag drives the 304, so this was wrong rather than harmful. - GET /api/connections/google/status — "Connected