TrailCam

Guides

Why does a GPX file show the wrong time after you import it?

Upload a perfectly good recording and the track sits exactly where it should on the map, but the clock next to it reads six hours early, or six hours late, or somewhere in the small hours of the morning for a walk you took at lunchtime. Nothing about the file is wrong. GPX simply does not store a timezone, and every service you hand it to has to supply one on your behalf.

The short answer

A GPX timestamp is written in UTC — Coordinated Universal Time — with no timezone attached to it at all. When a walk appears to have started at three in the morning after you upload it somewhere, the point itself is correct. What you are looking at is UTC being shown as if it were local time, or being converted using a timezone the receiving service guessed rather than the one you actually recorded in.

This is a display problem, not a data problem. The latitude, longitude, elevation and the order of the points are untouched by any of it. Only the printed clock time next to each one is affected.

Why GPX only ever stores UTC

Every timestamp in a GPX file follows the same pattern — a date, a time, and a trailing "Z" that marks it as UTC. The format does not offer a field for a timezone offset or a location, and that is deliberate rather than an oversight. A file recorded on one continent and opened on another has to mean the same instant in time regardless of where either of those things happened, and the only way to guarantee that is to fix every timestamp to a single reference that never changes. UTC is that reference. The cost is that converting it back to a time a human would recognise is left entirely to whatever opens the file.

Where the mismatch actually comes from

There is no single culprit — a few different things can each produce the same symptom:

  • The receiving service's profile timezone. Strava, Garmin Connect and similar services convert UTC to whatever timezone your account is set to, not to wherever the walk actually happened. Travel with your phone's account set for home and a route recorded abroad will display in your home time, not local time at the trailhead.
  • A viewer with no timezone logic at all. Some simpler tools just print the raw UTC value as if it were already local, which is the case that produces the most dramatic-looking gap — several hours, not a few minutes.
  • A daylight-saving boundary. A route recorded a few days either side of a clock change can end up an hour off from what feels right, because the fixed UTC offset used for the conversion does not always match the offset in effect at the moment you were actually walking.
  • The device's own clock at the time of recording. Rare, but a phone with the wrong system time will bake that error into every timestamp it writes, and no amount of correct timezone handling downstream will undo it.

What this does not mean

It does not mean the file is corrupted, and it is not a reason to re-record or re-export anything. Distance, elevation gain, pace and the shape of the route on the map are all derived from the coordinates and the spacing between timestamps, none of which change when the printed time-of-day is wrong. A route that looks perfect on the map with an impossible-looking start time is the single clearest sign that this, specifically, is what happened.

Fixing the displayed time

Check the timezone setting on whichever service is showing the wrong time — it is normally a profile or account setting, not anything to do with the file itself. That single setting, corrected once, fixes the display for every file you upload afterwards, not just the one you noticed the problem on.

Editing the raw timestamps inside the file is possible — it is plain text, and a fixed offset can be added to every one with the right tool — but it is rarely the right fix, since the timestamps were never wrong to begin with. It only makes sense if you specifically need a file whose printed times already match local time before it goes anywhere else.

What TrailCam does

TrailCam exports a route as GPX 1.1, the specification that Strava, Garmin Connect and Komoot all read, and its timestamps follow the same UTC convention every conformant GPX file uses. If a route looks like it happened at the wrong hour after being uploaded somewhere else, the fix is the timezone setting on that service, not anything about the export itself. Export is part of the optional TrailCam Pro upgrade; the app is free to download.

Questions

Does a wrong time in an imported GPX file mean it is corrupted?
No. The coordinates, elevation and order of the points are unaffected. GPX timestamps are UTC with no timezone stored, so the printed time depends entirely on how the app you opened it in chooses to convert that UTC value.
Can a GPX file store a timezone so this does not happen?
No — the format only stores UTC timestamps and has no field for a timezone offset. Converting to a local time is left to whatever software opens the file.
Will a wrong displayed time affect my distance or elevation numbers?
No. Those are calculated from the coordinates and the spacing between timestamps, not from the time-of-day shown on screen. A mistimed clock and an accurate route are not in conflict.

Recording your own routes

TrailCam is an iPhone app that records your route with GPS, keeps video clips, photos and voice notes pinned to the spot where you took them, and exports the result as GPX 1.1 or CSV. It is free to download.

Download on the App Store