How the errors are handled. The phone tracker buffers fixes while offline (in flight) and, on upload, stamps the whole batch at a fabricated time — the positions and their order are real, only the clock is wrong. Drawn naively that makes a line shoot across the map (a "teleport"). Four stages, run on load, repair it — and take drawn teleports on the current data from 89 to zero:

1. Detect — group fixes into internally-consistent chains; flag a chain broken-clock when it collides in time with a bigger one or is too tiny to trust.
2. Recover — re-derive each broken batch's single wrong time-offset by the shift that minimises total travel path (overlapping batches solved together).
3. Anchor — for flights path-min can't place (a transpolar leg with no GPS, or a no-signal long-haul), use the flight's real take-off/landing time (from live ADS-B + bookings) and lay its fixes into that window along the route. Any flight that still teleports is anchored; a correctly-timed one is left alone.
4. Remove GPS spikes — a single fix at an impossible position (a stray GPS jump / stale replay: impossible to reach and leave, with the neighbours joining cleanly without it) is the only kind of point ever removed. Anything left with a real position — including a broken-clock fix whose time couldn't be recovered — is drawn: as a muted dot with unknown time. No point is ever hidden for being a duplicate of, or near, another.

Recovered/anchored times are derived, not measured: they show on the map (magenta dots, flight paths) but are EXCLUDED from every statistic here, and tax-residence day counts come from the server-side classifier and never use them. New flights need no code change — resolve their real times (flight-times.py) and the same anchor places them.