Why do two apps show different moving time for the same hike?

The short answer

Moving time disagreements almost always come down to how each app decides you were stopped, not to any difference in what was actually recorded. One app might watch your GPS speed and subtract anything below a small threshold automatically; another might trust only a pause button you pressed yourself. A service you upload the file to afterward may ignore whatever moving-time figure the recording app already worked out and recalculate its own from the raw points, using its own threshold. All of that is deciding, not measuring, which is exactly why it does not come out the same way twice.

Moving time is a decision, not a reading

A timestamp is recorded once and never changes no matter who reads it back. Moving time is nothing like that — it is a number an app computes, after the fact, by walking through the sequence of recorded points and deciding, one stretch at a time, whether you were moving or stopped. Two apps applying two different rules to the identical sequence of points can land on two different totals, and both totals can be entirely reasonable readings of the same walk.

Automatic detection versus a pause you pressed

There are two broad approaches, and they fail in opposite directions.

Automatic detection

Some apps watch your GPS speed continuously and treat anything under a small threshold as a stop, subtracting it from moving time without you doing anything. It is convenient, but the threshold itself is a guess, and different services do not use the same one. Stand still where the GPS fix is a little noisy and a slow jitter in reported speed can sit just above one app's threshold and just below another's — one app quietly keeps that time in moving time, the other subtracts it.

Manual pause

The other approach is a pause button. It takes a deliberate tap, but it removes the guesswork: the app knows exactly when you stopped and exactly when you started again, because you told it directly rather than leaving it to infer that from a speed reading.

What happens when a route moves between apps

A GPX track point carries a coordinate, usually an elevation, and a timestamp — there is no standard field in a GPX file that marks a stretch as "paused" or "moving." That decision, if the recording app made one, generally is not something the file itself carries forward. So when a route gets exported and then opened somewhere else, the second app is not reading a moving-time figure out of the file at all — it is looking at the bare sequence of timestamped points and working out its own answer to "was this person moving right here," using whatever rule it uses for every other file it opens. A recalculated moving time is not a correction of the original one. It is a second, independent judgment made without access to whatever the first app actually knew about your intentions.

Short stops get rounded away differently

Pausing to retie a shoe or check a map for twenty seconds sits right at the edge of what counts as a real stop. Some apps subtract any detected stop no matter how brief; others quietly ignore anything under a floor of ten or fifteen seconds, on the theory that a stop that short is closer to measurement noise than to an intentional break. Neither choice is wrong, but a hike full of short pauses can pick up a noticeably different moving time from an app that keeps all of them versus one that rounds the shortest ones away.

Why the pace gap often traces back here, not to distance

Pace is distance divided by time, so a moving-time disagreement shows up as a pace disagreement even when both apps agree closely on distance. It is easy to see two different pace figures for the same hike and suspect the GPS track itself was measured differently, when the actual cause is upstream of distance entirely — the two apps simply divided a very similar distance by two different amounts of time.

The one number that should still match

Elapsed time is not a judgment call. It is the timestamp at the end minus the timestamp at the start, and that arithmetic does not leave room for two apps to disagree about the same file. If elapsed time itself comes out different between two services looking at the same recorded hike, the cause is something else — a timezone handled inconsistently, or a file that was edited between the two — rather than a difference in how stops get detected.

Things that trip people up

• Assuming a ten-minute gap in moving time means one app lost part of the recording — usually it means the two apps disagree about which minutes counted as moving, not that any data went missing.
• Comparing pace across two apps without first checking whether the underlying moving time matches — a pace gap with matching distance almost always traces back to time, not to the GPS track.
• Expecting a re-imported GPX file to carry over the original moving time exactly — the file itself does not store that figure, so the importing app is recalculating it from scratch with its own rules.
• Treating a recalculated moving time as more accurate than the one shown live during the hike — it is not more accurate, just differently computed, and it is working from less information than an app that actually watched you pause and resume in real time.

Where TrailCam fits in

TrailCam reports moving time from a pause button you press yourself rather than guessing from your GPS speed, so the figure shown after a hike reflects exactly the stretches you chose to pause, nothing more and nothing less. A route exports as GPX 1.1 or CSV, and the CSV summary keeps the moving time and pace figures alongside distance and elevation gain, so the numbers travel with the hike rather than getting recalculated by whatever opens the file next. Export is part of the optional TrailCam Pro upgrade; the app itself is free to download.