My web framework does a really good job of normalizing
datetime values on the way into the database, so I never have to guess about the data at rest - it’s always UTC. It’s one of those things that’s better to just conform to.
That’s more or less what should be happening, albeit with some enforced consistency. I send in either a UTC timestamp (that’s what some services give me) or the local time (that’s what some services give me) and the web framework does the job of making sure everything is saved as UTC.
Not all services provide this information.
Garmin sends me the start time of the activity in seconds since January 1, 1970, 00:00:00 UTC (Unix timestamp) … along with three paragraphs of caveats.
Yeah, one idea I have right now is to take the first coordinate of the activity to determine its time zone.
All that said, I’m realizing after some research that - up until the LifeMap time filter - I’ve pretty purposefully ignored the idea of time. Between the time filter and the Challenges, nothing much else worries about the time of the activity (with some edge cases where the date displayed would be wrong).
I dug into how each of the services send me the start time, and oh no. Garmin & Strava both send me a sane UTC value. Strava sends a verbose time zone entry. Runkeeper sends me local time, with an entry for the UTC offset (that I’ve been ignoring since 2013 ) MapMyFitness is being as unhelpful as possible by giving me a fully formatted timestamp value that uses the wrong time zone paired a text-version time zone entry.