A flight can land at 18:31 and reach its parking position at 18:47. The timestamps mark different events.
Actual landing time records when the aircraft lands on the runway. Actual on-block time records when the aircraft reaches its arrival stand or parking position.
An online travel agency (OTA) should use the timestamp its interface says it shows.
This distinction affects flight timelines, status labels and servicing screens. VariFlight DataWorks supplies structured flight data. The OTA controls how it stores, labels, and uses each field.
What Is the Difference Between Landing Time and On-Block Time?
Actual Landing Time and Actual In-Block Time are separate operational milestones.
The International Civil Aviation Organization defines Actual Landing Time (ALDT) as runway landing. Actual In-Block Time (AIBT), also called actual on-block time, records arrival at the parking position. EUROCONTROL defines AIBT as the time when the crew engages the parking brakes at the arrival stand.
| Arrival milestone | Industry term | What the timestamp confirms |
|---|---|---|
| Aircraft touches down | Actual Landing Time (ALDT) | The aircraft has landed on the runway |
| Aircraft reaches its stand | Actual In-Block Time (AIBT) or actual on-block time | The aircraft has reached its arrival parking position |
The interval between ALDT and AIBT is the taxi-in phase. Combining them into one field removes part of the aircraft journey.
Neither timestamp confirms that a specific traveler has entered the terminal, cleared immigration or collected baggage. These are aircraft milestones, not passenger milestones.
Why Does the Arrival Milestone Matter to an OTA?
The word “arrived” can create different expectations across an OTA product.
A traveler may interpret “arrived” as landed, while a support agent may interpret it as at the stand. If different fields support the same label, product surfaces can conflict.
The field choice affects whether the flight page says “Landed” or “At stand.”
It also affects when the timeline ends the airborne phase.
It changes which timestamp appears in servicing tools.
It also affects how records compare planned and actual arrival.
The value comes from giving each timestamp a stable meaning across the OTA’s data model and interfaces.
Which Arrival Fields Should an OTA Keep Separate?
An arrival record should distinguish plan, expectation and confirmed movement.
| Data group | Example fields | Role in the OTA system |
|---|---|---|
| Flight identity | Flight number, flight date, origin and destination airport codes | Match the correct dated flight |
| Planned arrival | Scheduled arrival time | Preserve the original itinerary baseline |
| Expected arrival | Estimated arrival time | Show the current operating expectation before landing |
| Runway arrival | Actual landing time | Confirm touchdown |
| Stand arrival | Actual on-block time, when available | Confirm arrival at the parking position |
| Operational state | Arrival, cancellation, diversion and return status | Prevent abnormal flights from following a normal arrival sequence |
| Time context | Destination time zone | Display the timestamp on the correct local date |
One field should not overwrite the others. Scheduled time records the plan, estimated time records the expectation, and landing and on-block times confirm different events.
How Should Arrival Data Move Through an OTA System?
An OTA needs a consistent path from the aviation data source to the customer-facing label.
1. Identify the flight. Match flight number, date, origin and destination before applying arrival data.
2. Normalize timestamps. Store the source timestamp and its time zone without changing its operational meaning.
3. Preserve milestones. Keep scheduled, estimated, landing and on-block values in separate fields.
4. Apply customer rules. Map the available milestone to a product label such as “Expected,” “Landed” or “At stand.”
5. Publish the selected state. Use the same mapping in the flight page, trip timeline and servicing tools.
The provider supplies the flight record. The OTA supplies the state model and presentation rules.
This workflow is different from notification engineering. Thresholds, snapshot comparison and event priority are covered separately in [How Flight Status API Helps Apps Build Reliable Delay, Departure, and Arrival Alerts](https://dataworks.variflight.com/blog/flight-status-api-reliable-flight-alerts/).
Which Arrival Time Should Each OTA Product Surface Use?
The correct timestamp depends on the question a product surface needs to answer.
| OTA surface | Question being answered | Relevant field |
|---|---|---|
| Original itinerary | When was the flight planned to arrive? | Scheduled arrival time |
| Live itinerary before landing | When is the flight currently expected? | Estimated arrival time |
| Flight tracking page | Has the aircraft landed? | Actual landing time |
| Detailed arrival timeline | Has the aircraft reached its stand? | Actual on-block time, when available |
| Historical trip record | What happened compared with the plan? | Scheduled and actual milestones retained separately |
For a flight scheduled at 18:00 and estimated at 18:35, it landed at 18:31.
It was on-block at 18:47.
The OTA can show “Landed” after 18:31.
It can show “At stand” after 18:47. It cannot infer that a traveler has completed the airport arrival process.
What Should an OTA Do When On-Block Time Is Missing?
Actual on-block time should be an optional field. Availability can vary by flight, airport, and source.
When it is unavailable, the OTA should not copy landing time into the on-block field. A transparent fallback can follow this order:
1. Show “At stand” only when actual on-block time is available.
2. Show “Landed” when actual landing time is available but on-block time is not.
3. Show estimated arrival before a confirmed landing event exists.
4. Keep cancelled, diverted and returned flights outside the normal arrival sequence.
The data model should distinguish `not available`, `not yet received` and a confirmed timestamp.
What Should OTAs Test Before Integrating Arrival Time Data?
The sample should include normal arrivals, long taxi-in periods, overnight flights and abnormal operations.
| Test area | What to verify |
|---|---|
| Field semantics | Landing and on-block time remain distinct |
| Flight matching | The timestamp belongs to the correct flight, date and route |
| Time zones | Cross-time-zone and overnight flights display correctly |
| Update sequence | Estimated and actual milestones do not overwrite one another |
| Missing values | The product has a defined fallback when on-block time is unavailable |
| Abnormal operations | Cancellation, diversion and return do not produce a normal arrival label |
| Codeshares | Marketed and operating flight records are matched according to customer rules |
| Historical storage | The system retains the milestones required for later review |
How Can an OTA Measure the Business Value of Clearer Arrival Data?
VariFlight DataWorks does not calculate the OTA’s return on investment. The OTA can measure the effect inside its own product after defining consistent arrival milestones.
Useful customer-side measures include support fixes, and labels that conflict across interfaces. They also include the share of flights using fallback states. Another measure is records that lose time-zone or milestone meaning.
These measures show whether the implementation gives users and internal teams a more consistent arrival state.
## How Does VariFlight DataWorks Support OTA Arrival Data?
The [VariFlight DataWorks Flight Status Data API](https://dataworks.variflight.com/products/flight-status-data/) provides structured operational fields. Relevant data can include scheduled arrival and estimated arrival.
It can also include actual landing and actual on-block time, when available.
Other data may include flight status, flight identity, and airport context.
OTAs can connect these fields to status pages, trip timelines and servicing tools. For broader applications, see the [VariFlight DataWorks OTA data solutions](https://dataworks.variflight.com/solutions/air-travel/).
VariFlight DataWorks does not issue tickets or process PNRs. It does not handle passenger identity.
It does not confirm that a traveler left the aircraft. It does not decide when a customer workflow should run. The customer owns interface labels, fallback logic, notifications, analytics and business decisions.
FAQ
Is actual landing time the same as actual arrival time?
Not always. In an air traffic context, actual arrival may mean runway landing. In an airline or ground-handling context, it may mean arrival in-blocks. Products should name the underlying milestone instead of relying on “arrival” alone.
What is actual on-block time?
Actual on-block time is the time when the aircraft reaches its arrival stand or parking position. EUROCONTROL defines it as the time when the crew engages the parking brakes at the arrival stand.
Which field should support an “arrived” label?
The OTA must first define the label. Use the actual landing time for a landed milestone, when it is available.
Use the actual on-block time for a confirmed stand-arrival milestone, when it is available.
Can flight data confirm that a passenger has entered the terminal?
No. Flight operation timestamps describe aircraft milestones. They do not confirm that a particular passenger has disembarked, cleared immigration or collected baggage.
References
– [ICAO MID ATFM Plan: ATFM Terminology and Definitions](https://www.icao.int/sites/default/files/MID/Documents/MID-DOC-014-MID-ATFM-Plan-V2.0.pdf)
– [EUROCONTROL Specification for Airport Operator Data Flow](https://www.eurocontrol.int/sites/default/files/content/documents/single-sky/specifications/EUROCONTROL%20Specification%20APDF%20Edition%201.0%20final%20web.pdf)
– [ICAO GANP KPI Overview: Actual Taxi-In Time](https://ganpportal.icao.int/PerformanceManagement/DataAnalytics)
