The time fields
GPX can timestamp the file and individual geographic points.
The optional <time> element appears in more than one context. In GPX metadata it describes the file creation time. Within a waypoint, route point or track point, it records the creation or modification time for that element. The surrounding XML tells you which meaning applies.
GPX 1.1 uses the XML Schema dateTime form and specifies Coordinated Universal Time for point timestamps. A typical value ends in Z, such as 2026-08-28T07:14:32Z. The Z identifies UTC rather than a local civil time.
Fractional seconds are allowed. They can retain sub-second timing from a recorder, although their presence says nothing by itself about the accuracy of the position or the clock.
What software can derive
An ordered series of timestamps turns a line into a timed record.
Coordinates establish where points lie. Timestamps establish when the observations were recorded. When a track contains sensible, increasing point times, software can calculate elapsed intervals and estimate movement between observations.
- Elapsed durationThe interval between the earliest and latest relevant point can describe the span of the log.
- Speed between samplesDistance divided by the time between two positions gives an estimate, not an instrument measurement stored by core GPX.
- Stops and gapsLong time intervals with little movement may indicate a stop. Long intervals across separate segments show missing continuity, not the path taken.
- Sequence checksRepeated or decreasing times expose records that need interpretation before pace or duration is trusted.
Moving time is not a GPX 1.1 core field. It is normally derived using an app's own definition of movement, speed threshold and gap handling. Two services can therefore produce different active-time figures from the same timed points.
Limits
A timestamp is evidence in the file, not proof of how it was created.
A planned route can be given generated times. A recorded track can have its times removed during export. Copying, converting or editing a file can also preserve old point times while changing the geometry. Timestamps are therefore a useful clue when comparing planned and recorded GPX files, but they do not settle the question alone.
The metadata time is also distinct from the point sequence. It may identify when the GPX document was created, which can be later than the activity. It should not be substituted for the first track-point time.
Local display introduces another source of confusion. A UTC value may be shown in British Summer Time or another local zone by the viewing software. The underlying instant has not changed. A copied value without its zone marker, however, becomes ambiguous.
A useful inspection
Read the first, last and awkward intervals.
- Locate
Separate metadata time from point time.
Check the element's parent before deciding what a value represents.
- Scan
Confirm that point times generally increase.
Out-of-order values can make derived duration, speed and playback unreliable.
- Inspect
Look around segment boundaries and pauses.
A large interval may be expected, but it must not be treated as a recorded connection across missing positions.
- Retain
Keep the UTC designator when copying a value.
Convert it for display only after the complete timestamp has been parsed.
Sources & scope
What this answer is based on.
The sources define GPX time fields and the XML dateTime form. Moving time and other activity summaries are derived by receiving software, not standard GPX core fields.