Ah, the time gap. It’s a time-honored bike racing tool used to tell riders how far they are from other riders who are up the road or chasing from behind. While the pros have motos zipping by with signs displaying the time gaps, amateur racers often don’t have that luxury.
This can lead to funny situations, like my buddy who was racing an outdoor cat 3 crit where three riders went off the front from the gun. They quickly opened a big enough gap that the chasing peloton lost sight, and soon enough, it was like the peloton had forgotten about the group up the road. It wasn’t until the breakaway caught the peloton from behind that everyone realized the podium had slipped from their grasp!
In Zwift we have a display on the right of nearby Zwifters that includes time gaps from you to each rider. Have you ever wondered how those gaps are calculated?
This past weekend I raced the DADurday Chase Race, where knowing the gap between your group and those ahead and behind is very helpful. While doing some quick time gap estimates based on the minimap I realized I had no idea how Zwift calculates time gaps. So I decided to figure it out!
How It Works
After doing some testing, I’ve discovered that Zwift’s gaps are based purely on distance. Or more accurately: Zwift’s time gap calculation assumes everyone is traveling at 30kmh.
This makes it an easy calculation on Zwift’s side–they just need to know the distance from one Zwifter to the next.
Here’s a simple example: if you are the red rider, traveling at 30kph, and the rider up the road isn’t moving, you would catch them in 60 seconds. In this example, Zwift would show a time gap of 60 seconds between the two riders.
The downside of Zwift’s time gap calculation method is that it’s only accurate when you are traveling at 30kph. Let’s look at more examples.
What about a flat race situation? Most of my flat races on Zwift find me sitting in the pack traveling between 40-50kph.
At this speed, the rider ahead is 40 seconds away–but Zwift will still tell me 60 seconds.
This disparity increases with speed, so on a descent when I’m traveling at 70kph the rider is only ~25 seconds ahead, but Zwift will tell me 60 seconds.
What if we slow down, like on a climb?
At 15kph (not an unreasonable climbing speed, especially on steeper climbs and/or for bigger riders), Zwift now drastically underestimates the time gap, showing 60 seconds when the next rider is really 120 seconds up the road.
This explains why, in a race situation, you might show a gap of 20 seconds to the lead rider on a climb. But when that rider crests the hill and begins to descend, the gap suddenly grows to 60 seconds! Did the leader attack? No. But they’ve increased their distance from you because they’re moving fast while you’re still crawling up the hill. Don’t panic, because you will be making up that distance soon enough!
ZwiftPower to the Rescue
If you want more accurate live time gaps in Zwift events, ZwiftPower has your solution. I chatted with James Hodges, the programming mastermind behind ZwiftPower, and he explained that ZwiftPower estimates time gaps based on 100-meter waypoints scattered throughout Zwift. The system is constantly logging the precise time when each rider passes each waypoint. It can then compare the times of riders for the same waypoint and thus display the gap between those riders.
Here’s one example of what this live event data looks like–note the “Time” column, which displays the number of seconds each rider is behind the leader. (In this particular case there is obviously a sizeable group of riders at the front of the race.)
To access these live time gaps, just find your event in ZwiftPower and click the “Live” link in the menu. Especially handy in chase/handicap races!
Reframing Time Gaps
Armed with this information about how Zwift calculates time gaps, perhaps it’s wise to begin thinking of the gaps not as time, but distance. The math is easy: 60 seconds of a “time gap” means the rider is 500 meters away. That 10-second gap which seems impossible to close? It’s 83 meters and change. You can do it!
Can it be better?
It seems Zwift’s time gap algorithm has room for improvement, but what would that look like? Should they implement a waypoint system like ZwiftPower? Is there something they could implement that would work even better? Or should they not change a thing? Share your thoughts below!
I’ve been watching the Tour de Zwift races recently and the time gap calculation is quite a glaring problem, especially on the Bologna course (round 4) with long flat, uphill and downhill sections. The commentators are continually referencing the time between the breakaway and the peloton but the numbers they give are never actually accurate – either too high on the flats and descents where they are well above 30km/h, or too low on the climb. It makes it look like gaps are opening or closing when they aren’t, which turns the commentary into a bit of a farce, which… Read more »
Useful article, ,I had worked out that Zwift time gaps were distance derived rather than time waypoint based but did not know that the distance to time conversion used a constant 30kmph. With that knowledge it’s pretty easy to translate the Zwift reported gap to real world distance. Thanks.
How hard would be to use the real speed vs a constant 30kph? I think it is pretty straightforward, am i wrong?
It is such a shame that Zwift manages to get so many basic things wrong yet waste their time with useless things such as the fence in group rides. They don’t work on improving the basics. This time gap issue has been around since the first time that “feature” was implemented. If it is not accurate and not working, then it should be in beta until it actually works.
@eric
Zwift may have changed the calculation. Each “second” now represents 10m, and each “minute” represents 600m.
In group rides, riders that have completed 2.2km more distance than me are shown as -3:40 (3x600m + 40x10m = 2.2km). Riders whom have completed 1.3km less than me are shown as +2:10 (2x600m + 10x10m = 1.3km)
That means the conversion in this article works at 36kmph.
Or maybe Zwift just took the 1sec=10m approach.
Thank you for testing and explaining the time gaps. Firstly, given that it’s a fixed 30km/h assumed value makes the time gap calculation a bit useless as you don’t know what speed the other riders are doing and you’d have to go at 30km/h to force the calc to work. Secondly, given that it’s actually a distance metric represented in time would it not make more sense to show the distance to the next rider? Based on the explanation I think it’s best not to show the time gap or to replace it with a distance gap or implement a… Read more »
Hi Eric, after recent issues with the displayed time gaps to HoloReplay I found your old article. How the gap is calculated does not make any sense to me nor do I understand Zwift’s approach. In any case ‘data’ of the nearby riders is required for calculation which probably performed on the client machine. Every nearby rider and so the HoloReply is mainly represented by the GPS coordinates at a certain timestamp. This data is available at any time on the client machine when connected w/ the host. If not, nearby riders would not be displayed. Consequently, the time gap… Read more »