On several FIT file exports times are totally off

[archaeop]

On several FIT file exports the times are off by days and hours. I could not find a clear indication, which activities / recording devices are affected, what I can say: I could only see the effect at activities recorded by a clock, eiteher Garmin or Polar. But a friend of mine using a Garmin 245 music has the effect, while my own activities recorded on a Garmin 245 music too are fine.

[archaeop]

Here is an example, which should be generally available:
https://www.strava.com/activities/10252700067
By re-importing the exported FIT file you can easily see the difference

[archaeop]

After several additional tests I see the following logic:
-the problem only occurs on runs, not on rides (sounds strange, but I could recreate this at sveral runs+rides of a friend, who records both on a Garmin forerunner 245 music)

• if the problem occurs, the date shown is always the current date, the time seems to be always in the future (from the time of export)
• the problem does not occur on my own runs, but seems to be there at all(?) runs of connected people
• the problem is also included in TCX file exports
• the problem was there with both Polar and different Garmin watches

[mayfield]

You pretty much nailed it. The date of an activity is unfortunately not consistently included in the activity data and depends on a bunch of seemingly unrelated factors like activity type and self vs peer activity. So when doing an export sometimes it has to guess or completely give up and just use the current date. You'll see something like this in the logs if you hit F12 before exporting...

The only option I've seen so far (not that there isn't a better one that I've not discovered) is to try and use the localized date shown in the HTML, ie. "Monday, November 20, 2023", but this is incredibly error prone and would require some horrific hacks to try and make work for all the hundreds of different locales used by strava users.

Here is the code that attempts to get the best date possible...

sauce4strava/src/site/analysis.js

Lines 1578 to 1615 in d13163a

	async function getEstimatedActivityStart() {
	// Activity start time is sadly complicated. Despite being visible in the header
	// for all activities we only have access to it for rides and self-owned runs. Trying
	// to parse the html might work for english rides but will fail for non-english users.
	const localTime = pageView.activity().get('startDateLocal') * 1000;
	if (localTime) {
	// Do a very basic tz correction based on the longitude of any geo data we can find.
	// Using a proper timezone API is too expensive for this use case.
	const geoStream = await fetchStream('latlng');
	let longitude;
	if (geoStream) {
	for (const [, lng] of geoStream) {
	if (lng != null) {
	longitude = lng;
	console.info('Getting longitude of activity based on latlng stream');
	break;
	}
	}
	}
	if (longitude == null) {
	// Take a wild guess that the activity should match the geo location of the athlete.
	const athleteGeo = ns.athlete.get('geo');
	if (athleteGeo && athleteGeo.lat_lng) {
	longitude = athleteGeo.lat_lng[1];
	console.info('Getting longitude of activity based on athlete\'s location');
	}
	}
	let offset = 0;
	if (longitude != null) {
	offset = Math.round((longitude / 180) * (24 / 2)) * 3600000;
	console.info('Using laughably bad timezone correction:', offset);
	}
	return new Date(localTime - offset); // Subtract offset to counteract the localtime.
	}
	// Sadly we would have to resort to HTML scraping here. Which for now, I won't..
	console.info('No activity start date could be acquired');
	return new Date();
	}

[archaeop]

Thank you very much for diving so deep into this problem.
For me, it would be sufficient, if the time would be in GMT, the most annoying thing currently is, that the time is offset by something variable. Even the duration seems always a bit off (a few minutes / hour)