Time calculation when crossing International Line Date

Richard1980

Registered User.
Local time
Today, 19:03
Joined
Aug 13, 2012
Messages
72
Hello everyone,
I am struggling trying to solve this task.
I have a form where I save flight data (departure & arrival time, flight time and so on). No problem about calculation of flight time between two cities if the flight does not cross the International Date Line (aka IDL) (Longitude 180°).
The problem comes up when the flight crosses that line. Accordingly to the general accepted rules, when the line has been crossed in a eastbound flight (i.e. Tokyo to Los Angeles), the date remains the same as the departure one.
When the line has been crossed in a westbound flight (i.e. Los Angeles to Tokyo), the date must be added by one day.
Tha main variable to be considered is: has the flight passed the IDL?
It is a very important variable, because if it is not true then I have not to change the arrival date, but if it is true, then I should consider where the flight is bound to modify accondingly to the (above) rule the arrival date and then calculating the flight time in a right way.
Is that quite clear?
How would you manage that?
Thanks, bye.

Riccardo
 
The only way that comes to mind would be a table of all the flights with a field stating whether it crosses the IDL.
 
You could approximate it if you had the latitude of the DEST and ORIG cities, and compared them to see if the shortest distance would cross 180°. But yeah, the only way to be sure is a boolean field in your flight table.
 
Records all times as GMT. All calculations will then work.

Record the time zone of each location in the locations table and use it to display the local time.
 
More:
Store in a table the operator input between 2 cities.
Whenever will have a couple StartCity - EndCity look in this table if the route pass or not the line.
If the record exist then automatically fill the appropriate control. If not, ask the operator and, after his input, add the information to this table.
 
Records all times as GMT. All calculations will then work.

Record the time zone of each location in the locations table and use it to display the local time.
The problem is exectly this. I already record GMT times, but the calculation in some situation gets crazy (i.e. UTC time for departure greather the arrival one: dep 1700z, arr 0500z) because the time field doesn't know that arrival day is the day after and the calculation is wrong.
So I thought to manage the field in "general date" format to perform a right calculation but the other face of the medal is that I cannot find a way to determine automatically arrival date, considering the (possible) IDL crossing.
:confused:
Don't if I described well the situation.
Thanks.
 
The GMT time seems to be the best solution.
Store the GMT relative time for each City (ex: +2 for GMT+2 ; -3 for GMT-3)
Then calculate the difference of GMT time between the cities.
Then to the calculated time of fly add this difference (be very careful to the sign)
 
I second Mihails solution.
Taking your example I get this:
Departure 10 Nov 1700Z from Tokyo. (Tokyo is at the +9 time zone so local departure time is 11 Nov 0200(+9))
Arrival 11 Nov 0500Z in Seattle. (Seattle is at the -8 time zone to local arrival time is 10 Nov 2100 (-8))

Keep in mind that when you go to GMT time, the date line is no longer something to be reckoned with. Passing the date line does not affect GMT, it only affects local time.
All there is left is to convert the local times to GMT. The effect of the date line is automatically accounted for in these calculations and you will not need to worry about them.

What you need to do is to convert your departure time to GMT with date.
If you know the flight time, add this to your departure time and then convert it to your destination time zone.
If you know the arrival time, convert it to GMT to get the flight time as the difference between your departure and arrival times in GMT.

You can find tables of the time zones for each city online however you need to take daylight saving time into consideration to make all your calculations right.
 

Users who are viewing this thread

Back
Top Bottom