Hi,
I’m using the FlightXML version 3 Rest API. I’m querying FlightInfoStatus with include_ex_data set to true. I’m on the Silver plan.
All the flights I get have “actual_blockout_time”=>{“epoch”=>0} and “filed_blockout_time”=>{“epoch”=>0} although the flights have arrived.
Why?
Thanks
Yes, include_ex_data controls whether you receive these fields:
Yeah, I would expect these blockin / blockout fields to be timestamps, but they just contain the value 0.
Why is that?
Those fields will not always available, depending on the airline and the airport it is operating at. They have a higher chance of being available for larger airlines, particularly those based in the U.S.
Ok, thanks. I’m usually mosty interested in European flights. Are there other ways to get the off-block / on-lock timestamps for a given flight, that may have a higher probability of being set?
Approximating those fields by using the actualdeparturetime and actualarrivaltime fields (an optionally adding a few minutes for taxi time) is actually what many airlines do themselves.
I see. This may be good enough in my case. Thanks 
Hi guys,
Sorry to bring this thread back to life…
I am a pilot flying for TUI airways in the UK and I have noticed that you do not provide gate times for any of our flights.
The string below is from your AeroAPI and is just one example which shows null for Out and In times - could you please help me understand why you are unable to provide this data?
{
“flights”: [
{
“ident”: “TOM727P”,
“ident_icao”: “TOM727P”,
“ident_iata”: “BY727P”,
“fa_flight_id”: “TOM727P-1652226019-ed-0000”,
“operator”: “TOM”,
“operator_icao”: “TOM”,
“operator_iata”: “BY”,
“flight_number”: “727P”,
“registration”: “G-TUIC”,
“atc_ident”: null,
“inbound_fa_flight_id”: “TOM727-1652045400-schedule-0307”,
“codeshares”: ,
“codeshares_iata”: ,
“blocked”: false,
“diverted”: false,
“cancelled”: false,
“position_only”: false,
“origin”: {
“code”: “EGNT”,
“code_icao”: “EGNT”,
“code_iata”: “NCL”,
“code_lid”: null,
“airport_info_url”: “/airports/EGNT”
},
“destination”: {
“code”: “EGBB”,
“code_icao”: “EGBB”,
“code_iata”: “BHX”,
“code_lid”: null,
“airport_info_url”: “/airports/EGBB”
},
“departure_delay”: -473,
“arrival_delay”: -473,
“filed_ete”: 2202,
“scheduled_out”: null,
“estimated_out”: null,
“actual_out”: null,
“scheduled_off”: “2022-05-11T08:34:15Z”,
“estimated_off”: “2022-05-11T08:26:22Z”,
“actual_off”: “2022-05-11T08:26:22Z”,
“scheduled_on”: “2022-05-11T09:10:57Z”,
“estimated_on”: “2022-05-11T09:03:04Z”,
“actual_on”: “2022-05-11T09:03:04Z”,
“scheduled_in”: null,
“estimated_in”: null,
“actual_in”: null,
“progress_percent”: 100,
“status”: “Arrived”,
“aircraft_type”: “B788”,
“route_distance”: 179,
“filed_airspeed”: null,
“filed_altitude”: null,
“route”: null,
“baggage_claim”: null,
“seats_cabin_business”: null,
“seats_cabin_coach”: null,
“seats_cabin_first”: null,
“gate_origin”: null,
“gate_destination”: null,
“terminal_origin”: null,
“terminal_destination”: null,
“type”: “Airline”
}
],
“links”: null,
“num_pages”: 1
}
We cannot provide the data if we don’t receive it from any of our upstream providers. In this case, your airline would likely need to send all OOOI events to OAG first (usually in the form of ACARS messages), which doesn’t currently appear to be happening.
Hi Bovineone, thanks for the reply.
Are you not able to simply track Transponder ON/OFF times or ground movements times like some of your competitors?
It’s quite a big deal for us as it is starting to effect our product - do you have any suggestions of how best to resolve this issue?
Transponder data and other machine-learning heuristics can be used to derive OOOI times when there is sufficient ADS-B surface reception coverage available. However, some of our more advanced time derivations are limited to accounts that are have our “FlightAware Foresight” product tier enabled. You will need to contact our sales department if you wish to enable that.
For that specific flight (TOM727-1652045400-schedule-0307) we detected avionics power on at 2022-05-11 08:19:15, and derived a synthetic OUT time of 2022-05-11 08:21:11.
We would be interested in the upgrade if the times were correct - unfortunately that time stamp is miles out from the actual OUT time, so it wouldn’t be much use to us.
I will see if I can resolve this externally.
Thanks anyway