The quick answer: for a jet, take the distance in miles, divide by 500, and add half an hour. London to New York is about 3,440 miles, so roughly 7 hours 25 minutes. The airlines schedule it at around seven hours eastbound and around eight westbound, so the rule lands between the two.
That difference between directions is the most interesting part of the question. This post explains where flight time comes from, why the rule of thumb drifts, and how to get a proper estimate for any pair of airports when you're building something that needs one.
What "flight time" on your ticket measures
The duration on a booking is block time: from the moment the aircraft pushes back from the gate to the moment it parks at the other end. It includes:
- Taxi-out. A few minutes at a quiet airport. At a busy hub in the morning peak it can be 20 minutes or more.
- Climb. Twenty minutes or so to reach cruising altitude, at lower speeds than cruise.
- Cruise. The part most people picture.
- Descent and approach. Including any holding if the destination is busy.
- Taxi-in. Usually shorter than taxi-out, but not at airports where the runways are far from the terminal.
Airlines also add a buffer, often called schedule padding. In the US a flight counts as on time if it arrives within 15 minutes of schedule, and a little slack in the published time makes that easier to hit. That's a big part of why flights so often "arrive early".
So the time on your ticket is not the time spent in the air. On a short flight, the ground and the climb are a large share of the total.
Why the rule of thumb works, and where it doesn't
"500 mph plus 30 minutes" works because airliners cruise at about Mach 0.78 to 0.85. Depending on altitude and temperature, that's roughly 450 to 500 knots, or 520 to 575 mph. Knock a bit off for the slower climb and descent and 500 mph is a fair average over the whole flight. The 30 minutes covers taxiing at both ends.
Where it goes wrong:
| Route | Great-circle miles | Rule of thumb | What airlines typically schedule |
|---|---|---|---|
| London – New York | 3,442 | 7h 23m | About 7h eastbound, about 8h westbound |
| London – Madrid | 774 | 2h 03m | About 2h 20m to 2h 30m |
On London to Madrid, the rule comes in short. Short flights spend a larger share of their time taxiing, climbing and descending, and London's airports are among the busiest in Europe, so taxi and holding times are long. On London to New York, the rule can't know which way you're going.
Why going east is faster
The jet stream is a band of strong wind at roughly the altitudes airliners cruise, and it blows from west to east. In winter its core regularly exceeds 150 mph. An aircraft heading east picks up that wind as extra ground speed, and one heading west flies into it.
Airlines plan around it. Westbound flights often fly a different route from eastbound ones to stay out of the strongest headwind, and they're scheduled longer. On a windy winter night the effect can be dramatic. In February 2020, a British Airways 747 flew from New York to London in 4 hours 56 minutes, helped by a jet stream that pushed its ground speed past 800 mph during Storm Ciara.
That's why a single "flight time" for a route is always an average. The actual time on a given day depends on the wind that day.
Other things that change flight time
Aircraft type. A widebody cruising at Mach 0.85 is faster than a narrowbody at Mach 0.78. Over a long route that adds up to a noticeable difference, while on a one-hour flight it hardly matters. The aircraft performance post goes into this.
Routing. Aircraft don't fly the great circle exactly. They follow airways, avoid restricted airspace and go around weather. Some routes are much longer than the straight line because of closed airspace.
Congestion. Holding patterns at busy airports add time at the end, and ground stops and flow programmes add it at the start.
Getting an estimate by API
If you're building a travel app, a connection planner or a scheduling tool, the rule of thumb isn't good enough. The flight time endpoint returns a gate-to-gate estimate from a model trained on historical operations. It takes two airport codes, IATA or ICAO, and an optional aircraft type:
curl "https://skylink-api.p.rapidapi.com/ml/flight-time?from=LHR&to=MAD&aircraft=A320" \
-H "X-RapidAPI-Key: YOUR_KEY" \
-H "X-RapidAPI-Host: skylink-api.p.rapidapi.com"The response has the great-circle distance_nm, an estimated_minutes point estimate, a ready-made estimated_hours_display string such as "4h 54m", and min_minutes and max_minutes bounds.
A passenger-facing label should show the range as well as the point estimate:
import requests
BASE = "https://skylink-api.p.rapidapi.com"
H = {"X-RapidAPI-Key": KEY, "X-RapidAPI-Host": "skylink-api.p.rapidapi.com"}
def get(path, **params):
r = requests.get(f"{BASE}{path}", headers=H, params=params, timeout=(5, 20))
r.raise_for_status()
return r.json()
def how_long(frm, to, aircraft=None):
params = {"from": frm, "to": to}
if aircraft:
params["aircraft"] = aircraft
p = get("/ml/flight-time", **params)
lo, hi = p["min_minutes"], p["max_minutes"]
return (f"About {p['estimated_hours_display']} gate to gate "
f"(usually {lo // 60}h {lo % 60:02d}m to {hi // 60}h {hi % 60:02d}m)")Pass the aircraft type when you know it. The docs say it matters most on long routes, where narrowbody and widebody cruise speeds pull apart. If you only have a tail number, aircraft lookup gives you the type code.
Plan connections against the slow end
For a connection, the average is the wrong number. Plan against max_minutes:
from datetime import timedelta
def connection_ok(first_leg, departs_utc, next_departs_utc, min_connect=60):
"""Plan the connection against the slow end of the range, not the average."""
p = get("/ml/flight-time", **{"from": first_leg[0], "to": first_leg[1]})
worst_arrival = departs_utc + timedelta(minutes=p["max_minutes"])
spare = (next_departs_utc - worst_arrival).total_seconds() / 60
return spare >= min_connect, round(spare)Keep all the times in UTC. Mixing the local times of two airports is the classic way to get a connection wrong by an hour; Zulu time in aviation covers why.
What the estimate can't tell you
The docs are clear that wind and live en-route weather are not inputs. The estimate is a statistical average for the route and aircraft category, not a forecast for tomorrow's 9am departure. That makes it right for planning, schedule comparisons and "about how long?" labels, and wrong for "when will this flight land?".
For a flight that's already airborne, use live data instead. Flight status gives the airline's current estimate, and a live position from ADS-B with its ground speed tells you how the flight is actually doing, including whatever the jet stream is doing to it. Predictive ETAs covers that side.
The docs also note that if the model is temporarily unavailable, the API can fall back to a simpler distance-and-speed calculation, and model_version tells you which you got. Log it if you're keeping the estimates.
Results for a city pair don't change often, so cache them. You can try the endpoint on the free trial, which is for personal, non-commercial use. For a commercial product you'll need a paid plan.