Global activities and time zones

In this more complex example, we introduce a sample application that displays users’ GPX activities from all over the world. Routes are drawn on the map, and next to them there is a list of activities sorted by start time.

The application demonstrates that it is not enough to work with just one time. Local time is clear for the user (we see that they started at 9:00 in the morning), but it does not allow fair comparison across continents. Two trips with the same local time may actually start hours apart in UTC.

Therefore, it is necessary to store and use both timesUTC for sorting and comparison, and local time for display. Conversion between them is handled by the TimeZone API, which returns the time zone and valid offset relative to UTC based on location.

What the demo does

In JavaScript, three activities are simulated (e.g. bike trips) from America, Europe, and Australia. The data contains:

  • the route location (start and several points),
  • the start time in UTC (just like in GPX files).

The application then uses the TimeZone API to convert the UTC time into local time at the starting point.

  • The map on the left shows the activity routes.
  • The list on the right shows the activity name, local time, and UTC offset.
  • Sorting is done by UTC, even though by local times the order would look reversed.
  • This is just a demonstration. In a real application, time conversions would typically happen on the backend when uploading GPX data.