…and now OpenFlights keeps track of it too, since with today’s release our very first feature request was completed: flight arrival and departure times are now supported.

You’d be excused for thinking that this doesn’t sound too complicated, but the devil is in the details: to work out when a flight departing Los Angeles lands in Singapore, it’s not enough to know how long it will take, you need to account for time zones and daylight savings time as well.   It also requires keeping all the data coherent: if the user changes the duration of a flight, the arrival time must change as well, and vica versa.

To see the timezone calculations for the current flight, hover your mouse over the icon (in Detailed editor only), and to check the DST zone setting of any airport, pop up the Airport Search window by clicking on or .  An example:

This tells you that LAX is in UTC-7 (with DST active on April 30th) and SIN is in UTC+8 (no DST).  With an estimated flight duration of 18:01 plus the time difference of 15 hours, the flight arrives at 8:01 AM, two days after departure.

Handling DST is particularly complicated, as not only does DST start and end on different days every year, but it does so differently from country to country.  Currently, OpenFlights understands five flavors: European, North American (US/Canada/Mexico), South American (plus a few African countries), Australian and New Zealand, but there are many exceptions not yet coded in and you can help by spotting wrongly tagged airports, eg. many smaller airports in the DST-less states of Arizona, Hawaii, Queensland and the Northern Territory.   More gory details can be found in Help: Time.

Last but not least, departure times are also now supported both in OpenFlights’ native CSV format (bumped to v0.4, see spec) and in FlightMemory HTML imports.  Since arrival time can be computed from departure time and duration, it is not stored.

Disclaimer: One sentence in this blog post was provided by our sponsor. Guess which!

Fruit flies like a banana,
-jani