Understand IATA codes, timezone traps, and local-time semantics in flight data

Steps

1. IATA airport codes (3-letter, e.g. JFK) and city codes (also 3-letter, e.g. NYC) are distinct — city codes may map to multiple airports; always resolve to airport code before passing to booking APIs.
2. Flight departure and arrival times in booking APIs are almost always expressed in local time at the respective airport, not UTC — a 14:00 departure from LHR means 14:00 London local time.
3. To compute flight duration correctly, convert both departure and arrival local times to UTC using the IANA timezone identifier for each airport (e.g. Europe/London, America/New_York), then subtract; never subtract local times directly.
4. Overnight flights and DST transitions can make naively computed durations wrong by an hour or more — always use a timezone-aware library (e.g. Python's zoneinfo or JavaScript's Temporal API) for these calculations.
5. Airport timezone data is not included in most flight APIs — maintain or source a mapping of IATA airport code to IANA timezone (e.g. from OpenFlights or a maintained open dataset) and join it locally.
6. When displaying times to users, show local time with explicit timezone abbreviation (e.g. '14:00 BST') plus the UTC offset; never show bare local time without context.