I imported a GPX file and used Extract Brief Visits to begin cleaning up the data. It appears that the visit was extracted successfully, but it was saved to the timeline with its timestamps converted to my phone’s local timezone instead of preserving the original GPX timestamps.
I’ve emailed the debug information, the original GPX file, and a screenshot of the extracted visit.
During my testing, I believe BIG-645 occurred, so the debug logs may contain unrelated information.
From what I can tell, the GPX itself imported correctly. The track starts at 10:01 in the location’s local timezone, as expected. However, after running Extract Brief Visits, the extracted visit appeared starting at 6:01, which corresponds to 10:01 converted to my phone’s local timezone. This suggests that the extraction process is incorrectly interpreting or converting the timestamps, even though the initial GPX import preserves them correctly.
Good news on this one: your data is fine. The GPX import stored the recording timezone against every sample, and it’s still there — nothing was converted or lost on the way in.
What you hit is a display bug confined to that screen. The Extract Brief Visits list formats its times using your phone’s current timezone rather than the timezone the data was recorded in, so a 10:01 stop reads as 6:01. The extracted visit itself keeps its true times — if you view it in the timeline day view it should show 10:01, as expected.
Your report also widened an existing ticket. We already had this filed against the segments view (BIG-535), and checking your case against the code turned up the same oversight on several other screens, so it’s now one fix across all of them rather than a one-off.
And you were right that BIG-645 showed up during your testing — that one’s fixed and will be in the next release.
The hotel visits have the wrong end times, the start and duration display correctly. Possibly a case you should check if it is included/corrected in BIG-535.
Checked against BIG-535: as filed, it covers a different surface — the Trip Segments view formatting times in the device’s timezone rather than the recording location’s. What your screenshots show is at least a close cousin, but it may be its own thing: in your first screenshot the Mercure row disagrees with itself — 13:58 plus the displayed 2h 11m lands at 16:09, not the 16:47 shown — and 38 minutes isn’t a clean timezone offset either. So: recorded on BIG-535 with your screenshots, flagged as a possibly-distinct case, and the two will get checked together when that area is picked up.
If it’s convenient sometime: a diagnostics export for the day in that first screenshot would give us the row’s underlying data to check the display against.
A correction to the reply above: the row’s times got read upside down on our side. Timeline rows show the end time on top and the start time on the bottom — so your Mercure row actually reads start 16:47 with duration 2h 11m, putting the true end at 18:58. And the displayed 13:58 is exactly 5 hours behind that: 18:58 in Zurich summer time (UTC+2) is 13:58 in UTC−3.
So your timezone hypothesis was right after all — the end time is being rendered in a different timezone from the start time, which is exactly BIG-535’s class of problem. The ticket’s been updated to reflect that, with your screenshots as the cleanest specimen of it yet.
The diagnostics export ask from the earlier reply still stands, if convenient sometime — it would confirm which timezone the row’s underlying data carries and make the fix’s test case exact.
Right — with the code fully walked, here’s the corrected and (this time) grounded picture, superseding the earlier attempts in #4–#6:
How the timeline row works, by design: start and end times each render in their own local timezone, carried by the item’s first and last samples. That’s deliberate — it’s how a border-crossing day shows sensible times at both ends — and your row demonstrates it working: the start renders correctly in Zurich time because the first sample carries the right timezone.
What’s actually wrong: the item’s last sample is carrying a wrongly-stamped timezone. We traced the mechanism into the GPX import path: each imported sample gets its timezone from a reverse-geocode lookup, but when an individual lookup fails mid-import (an offline moment, a timeout, or the geocoding service rate-limiting a big import), the sample silently keeps the device’s timezone instead — a plausible-looking wrong value. Filed today as BIG-702. And healing existing data is BIG-342 — a coordinate-based timezone backfill that turns out to have been filed back in March, gone missing in an old archiving sweep, and revived today with your case attached. So your report just resurrected a lost ticket.
The diagnostics export ask stands, now sharper: the export for that day will show the end samples’ stored timezone values directly — we’re expecting the last sample(s) to carry your device’s offset rather than Zurich’s, which would confirm the whole chain.
Thanks for the patience with the corrections churn on this one — your screenshots ended up fixing three tickets’ worth of record.
Data files sent by email, subject “GPX import timezone problem - BIG-702”.
I noticed that the problematic visits were all at the very end of the file, just before the data gap.
Also, please note that some of the problematic visits consist of data from different days that I manually joined by correcting the gap between them to stationary.
The files arrived safely, and they settle it: the end samples do carry your device’s offset rather than Zurich’s, exactly as predicted — with a twist that makes your two side-notes the key observations.
The imported track points themselves are fine: every GPX-sourced sample on the days checked carries the correct Zurich timezone, thousands of them without a single miss — the import did its job. The wrongly-stamped samples are the data-gap bookends. A gap’s marker samples have no coordinates (there’s nothing to look a timezone up from), so they get the timezone the device had when the gap was created — and since gaps are built during processing, for imported historical data that’s your device’s timezone today, not Zurich’s at the time. Same wrong-default as described above, different doorway in.
That’s why the problem visits all sit right against data gaps: when a gap’s bookend sample ends up inside the neighbouring visit — which is exactly what happens when you correct a gap to stationary and it folds in — the row renders that end’s time in the bookend’s timezone. Your Mercure row shows the end result plainly: 179 correctly-Zurich samples, then two gap bookends at the very end carrying UTC−3, and the last sample is what the row’s end time renders from.
Both tickets now carry the specifics: BIG-702 for stopping the wrong stamp at the source, and BIG-342’s heal with a note that the gap bookends need a different repair than the coordinate lookup, since they have nothing to look up from.
Thanks for the exports, and for the two observations — they pointed straight at it.
