Scheduled vs Estimated vs Actual Flight Times, Explained

A flight has three different times for departure and three for arrival — scheduled, estimated and actual — and using the wrong one is the most common flight-data bug. Here is what each means, when it changes, and which to trust.

August 2, 2026 · · 4 min read

Almost every flight-data bug traces back to one mistake: treating a flight as if it has a single departure time and a single arrival time. It doesn't. Each has three — scheduled, estimated and actual — and they answer three different questions. Read the wrong one and you dispatch a driver to a printed time that moved two hours ago, or you mark a flight "on time" using a number that was only ever a plan.

This guide explains what each time means, when it changes through a flight's life, how they appear in the API, and a simple rule for which one to use.

The three times

• Scheduled — the published plan. Set when the schedule is filed, often months ahead, and it does not move. It answers: when was this flight meant to operate?
• Estimated — the current best prediction. It updates continuously as the day unfolds — traffic flow, a late inbound aircraft, weather, a revised gate time. It answers: when do we now expect it?
• Actual — what really happened, recorded as it happens. It exists only once the event has occurred. It answers: when did it actually go / arrive?

How they change through a flight's life

• Before the day of travel: only scheduled exists. Estimated usually equals scheduled; actual is empty.
• Hours before: estimated starts to move as the operation firms up — the inbound aircraft, crew, and traffic flow all feed it. This is the number that matters most now.
• At the gate / on the runway: the actual departure is recorded. From here, actual departure is fixed and attention shifts to estimated arrival.
• En route: estimated arrival keeps refining from the aircraft's live progress.
• On landing: the actual arrival is recorded. The flight's timeline is now complete and factual.

Departure and arrival each have all three

The three times apply independently to both ends of the flight. In the API they arrive as time buckets on each leg — gateDepartureTimes and gateArrivalTimes, each with scheduled, estimated and actual — plus the runway events, takeoffTimes.actual and landingTimes.actual:

{
  "gateDepartureTimes": { "scheduled": 1785657600, "estimated": 1785659100, "actual": 1785659100 },
  "gateArrivalTimes":   { "scheduled": 1785685200, "estimated": 1785686700, "actual": null },
  "takeoffTimes":  { "actual": 1785659760 },
  "landingTimes":  { "actual": null }
}

In this snapshot the flight has pushed back (gate departure actual is set) and taken off (takeoffTimes.actual), but has not landed — so gate arrival actual and landingTimes.actual are still null, and gate arrival estimated is the number to trust for the arrival.

UTC vs local — the second half of the same problem

Every time above is epoch seconds in UTC. A flight departs and arrives in two different local zones, and "16:25" is meaningless without knowing whose clock it is on. Each airport ships its IANA time zone as TZ (for example Asia/Dubai, Europe/Berlin) — convert the UTC value using the destination's TZ for arrival and the origin's for departure. Never display a UTC time as if it were local, and never assume both ends share a zone.

The simple rule: which time do I use?

• Use actual if it exists. Once recorded, it is the truth — for reporting, on-time performance, and closing out a job.
• Otherwise use estimated. For anything forward-looking — dispatching a pickup, holding a connection, staging a shuttle — the estimate is the live answer.
• Use scheduled only as a label. It is the plan and useful context, but it is the wrong number to act on the day of travel.

Put simply: actual > estimated > scheduled. Prefer the most real value available, and fall back only when the more real one isn't there yet.

Frequently asked questions

Why is the actual time null?

Because the event hasn't happened yet. Actual departure is empty until the flight leaves; actual arrival is empty until it lands. Fall back to estimated in the meantime.

My estimated time keeps changing — is that an error?

No — that is the point of it. Estimated is a live prediction that refines as new information arrives. If you want to be notified only on meaningful moves, use monitoring with a sensitivity threshold rather than polling.

What is the difference between gate times and take-off/landing times?

Gate times are "out" and "in" at the gate (pushback and arrival at stand). Take-off and landing are the runway events — wheels-up and touchdown — which is why they are reported as actual events once the aircraft has flown.

Should I show scheduled or estimated to a customer?

Show estimated (clearly labelled as "expected"), because it reflects reality on the day. Keep scheduled available as the original plan, but don't make decisions on it.

Are the times UTC or local?

UTC epoch seconds. Convert to local using each airport's TZ — the destination's zone for arrival, the origin's for departure.

Three times, one rule: prefer the most real value you have. Read actual when it's there, estimated when it isn't, and treat scheduled as the plan it always was — and your dispatches, connections and reports will line up with what actually happened.