I have this issue and the recent FIT files wont even load to Garmin manually (but will to other sites).
I have traced the issue to the timestamps in the FIT file produced by ZWIFT - Local_timestamp is 31/12/1989 which seems to upset Garmin with their addtional checks. Running the FIT file through the corrupt time fixer tool at FITfiletools fixes it and it then uploads to Garmin. I have raised tickets with both Garmin and Zwift, so hopefully something will get done.
For those still having the issue can you check:
- Can you upload the FIT file manually to Gramin or does it fail?
- if you download fit file explorer have a look at the local_timestamp (see below) - is it set to 1989?
- Raise a ticket with Zwift and Garmin so they know it is a real problem and they may fix it (Zwift can fix the FIT file, Garmin coudl relax their checks).
@Rowdy - Have a look at the new replies to this thread. The issue is still here and appears to be an issue with timestamps on the FIT file. It looks like it should be an easy fix for Zwift to sort out, simply set the local_timestamp correctly rather than leave it as 31/12/1989.
My fit files are the same (default to 1989 which is the default standard if not populated by an application) and they load without issue to Garmin. I also tried using that particular Corrupt Time Fixer to see if it populated that field - it didn’t.
Is it possible the Corrupt Time Fixer is fixing something else? It’s normally used to fix holes in the data stream written to the fit file caused by local network issues such as wifi drops.
@Dean The corrupt file fixer actually changed the timestamp to match local_timestamp (setting both to 1989) which seems to fix the issue/enable Garmin to upload. The actual data still has the correct 2022 timestamps. I had checked zwiftalyser for any wifi dropouts and had none at all (The PC is within 1 metre of the router). It is frustrating as Garmin sync has always worked for me until the last couple of weeks (seemingly at the same time as the last big zwift update, but can’t be sure). is is also only Garmin that rejects the FIT files.
Right, so local_timestamp is not the problem, it is the timestamp variable needing to be adjusted to local_timestamp. Thats a little different.
OK, odd as fitfiletools doesnt change any fit files local_timestamp nor timestamp variables I have collected from people over the years but glad that you have identified what works for you. Zwift have a backlog of bugs so hopefully they sort you out soon.
@Dean You have prompted me to do a little more digging with the FIT files. So this is what I found between the Zwift FIT and the Fitfiletools corrected FIT:
- Device Info on the Zwift Fit file had a timestamp 6/1/2015. Fit file tools kept this in the modifed file.
- The data record in the Zwift Fit file had the correct dates/times for each item of data (2022), but the fitfiletools changed them all to 2015 dates to match the device_info timestamp probably.
- File_id unchanged between the FIT files.
- Activity - both fitfiles had local_timestamp set to 1989. The Zwift FIT had timestamp set to the correct time / date (2022), but Fitfiletools changed this to 2015 to match the device_info timestamp.
- Session - Indentical info in both FIT files - start time was correct (2022) in both. However the Zwift file had a timestamp of 2022 (correct), but fitfiletools changed this to 2015 (to match the device_info timestamp?).
- Lap - All the timestmps in the Zwift file were correct, but fitfile tools also changed these to 2015 (again to match device_info timestamp).
So the issue seems to be that the wrong timestamp is being recorded in device_info. However, I have gone back to some older FIT files and they all have 2015 (recorded on different devices as well), so this isnt a new issue, but perhaps Garmin have changed their checks??
The screenshot below shows two fit files, the top one is the corrected one that does upload.
2015 is also a red herring as it is also a default timestamp in Device_info as is the 1989 in the Activity local_timestamp field - these are both default values if no data is specifically written. I have no doubt that you have a corrupt time/date field(s) in your data but neither of those that are the cause. My guess is the problem data is in Records somewhere.