The packet timestamp parser rejects valid RFC3339 timestamps that have a numeric UTC offset but no fractional seconds. For example 2026-09-28T22:37:55+00:00 and 2026-09-28T18:37:55-04:00 fall through all five layouts and use server receive time; the equivalent fractional form is accepted.
Reproduced against the current internal/ingest/packet.go layouts on accepted dev db30c9b5, and observed during the Pi integration smoke check. time.Parse(time.RFC3339Nano, input) accepts both forms. This is a timestamp-correctness and warning-volume issue; it does not establish a cause of MQTT packet loss or the older counter discrepancy.
A focused fix should accept RFC3339 offsets with and without fractional seconds, retain documented support for timezone-less observer formats and the existing skew policy, and add regression coverage for offset/no-offset, subsecond and invalid inputs. Review separately from the completed queue/route-lock integration.
The packet timestamp parser rejects valid RFC3339 timestamps that have a numeric UTC offset but no fractional seconds. For example
2026-09-28T22:37:55+00:00and2026-09-28T18:37:55-04:00fall through all five layouts and use server receive time; the equivalent fractional form is accepted.Reproduced against the current
internal/ingest/packet.golayouts on accepted devdb30c9b5, and observed during the Pi integration smoke check.time.Parse(time.RFC3339Nano, input)accepts both forms. This is a timestamp-correctness and warning-volume issue; it does not establish a cause of MQTT packet loss or the older counter discrepancy.A focused fix should accept RFC3339 offsets with and without fractional seconds, retain documented support for timezone-less observer formats and the existing skew policy, and add regression coverage for offset/no-offset, subsecond and invalid inputs. Review separately from the completed queue/route-lock integration.