Automatically determine timezone for source and destination airports

[nirenjan]

A flight departing San Francisco (SFO) on May 1st at 1315 would land in New Delhi (DEL) at 1730 on May 2nd. While this is somewhat related to #31, the duration calculation also needs to take the time zones into account.

The default duration calculation simply takes the difference of the times provided, giving 255 minutes (4h15m), but in reality, the flight would have departed on May 1st at 2015 UTC, and landed on May 2nd at 1200 UTC, giving a total flight time of 15h45m.

[pbogre]

I previously open an issue about this. However, implementing it this way (automatically detecting time zones) would mean that people who put departure and arrival date based on the same time zone (which is the way I do it) would get incorrect duration calculation.

I think the best way to solve this would be adding a arrival_date, since it fixes this problem for both types of people. Would that work for you?

edit: this would also work as a fix for #31

[pbogre]

I had a closer look at this issue and realized that the commits above don't solve this problem, so what I commented above is just wrong. They do close #31, however the calculation of duration is indeed still affected by time zone differences.

As I commented above, this was never a problem to me because I always set the arrival / departure times based on the same time zone (for example, if I fly from Germany to Japan, the arrival and departure times will both be for the Germany time zone). This is a way to get around this issue for now, but I do aim to fix in this the future.

note for future me: currently where we calculate the duration, we also have access to information about both airports (given that they are AirportModels and not strs), this way we can access their timezone like Rome/Italy by getting {airport.city}/{airport.country}. Then we can create the datetime.datetime objects taking into account their timezone, and I think python will handle the proper difference when doing arrival - departure.

[pbogre]

After looking into this a little bit, the change isn't exactly how I thought. First, the standard for timezone names is "Continent/City", not "City/Country", but that's not the problem. Parsing timezone as a string to tzinfo requires at least pytz, but since airports don't come with continent data (more on this soon) my initial approach was to try and use their latitude and longitude values, which means installing another module (tzwhere). However I had no success with this module.

But, the airports database from which I created the airports.db file in this repo (linked in the README), also has the timezone name as a field, but I removed it because I didn't deem it necessary. I can create a new airports.db file that contains that field, implement it in the various models for both backend and frontend, and finally use it when calculating the time difference. The problem is that this field is not available for all airports, which means that this functionality would not work for all origins/destinations, which isn't satisfying.

I'll mark this issue as help wanted for now.

[nirenjan]

I did find timezonefinder package which will get the timezone for a given latitude/longitude combination, and it's fairly fast. This might be worth considering.

[nirenjan]

We don't necessarily need to keep the package as a dependency, but it could be useful enough to get the timezones for the airports that don't have the timezone in the parent DB.

[pbogre]

That's a good idea.

If we do implement this feature, how could we still allow people to not use separate time zones for departure/arrival times? Because that's the way I would like to keep doing it.

Maybe a checkmark in the UI that, when enabled, informs the endpoint that it should consider separate time zones.

Since this issue seems to have increased in complexity, for now I'll keep assuming users use the same time zone for both departure and arrival, and if it gathers interest i'll implement it. I would like to keep this project as minimal as possible to have a manageable scope, I hope you understand.

[simonpt]

@pbogre, while I appreciate that you like to enter departure/arrival times using the departure timezone, it's actually very common to have the departure/arrival times expressed in the local timezones. For example, I just entered some historical flights from old hardcopy itineraries provided by travel agents, and I had to convert the arrival times back to the departure timezone before entering them. Then I realised that daylight saving rules have changed over the years, so I used timeanddate.com to calculate the correct timezone differences for the actual dates of the flights. It actually gets quite complicated, doesn't it? Got me wondering how you would code for all that.

For some really old flights, all I had was rubber stamp marks in old passports (no departure/arrival times), so I really appreciated being able skip the times in Jetlog and just enter a duration, which I calculated by googling "flight time from a to b". Hey, perhaps a future version of Jetlog can estimate the flight time...

I like your idea of a checkmark in the UI to change the interpretation of the arrival time's timezone. But, yeah, good luck working out the correct time difference.

May I say how impressed I am with what you've created. It very nicely helps satisfy my desire to log my historical flights and produce some cool stats. I tried the same with a highly-rated mobile app, but turned out that it only lets you log flights that it knows about, so if you go too far back in time, you can't enter the flight. No such problems with Jetlog. Thanks!

[jamess60]

I think ultimately, it should be all flight times in local time (as it would be in the real world), Jetlog is timezone aware, but an option to override start/end time and add a manual duration instead could be useful.

Regarding the Continent/City issue, there is a complete list of global airports and their timezones here .

Might be able to use something like this to handle DST

[pbogre]

One way to (at least temporarily) solve this problem might be to add a duration input when creating a flight. This input would show the automatic calculation value, and if it is not correct (i.e., you want it to actually be based on time zones), the user can always set it manually.

Of course this isn't really a fix to the problem, but it does remove all the complications of automatic time zone detection. The main issue I have with this feature is that supporting both modes of input (using the same time zone for both times vs using the time zones corresponding to the airport) becomes quite messy.

All of this is to get a different method of duration calculation, because ultimately the arrival/departure times don't really matter. For these reasons I think I'll implement the duration input I described above as a temporary fix to this problem. If anyone has something to add to this, please do :)