Flights not scheduling or flying

[Unknown98]

Strange, those routes should be operating fine. I'll have to see if I can de-bug them and figure out why it's not scheduling properly.

Currently there are issues with the scheduling code where it will sometimes not schedule the entire route. This leaves aircraft in the wrong locations and prevents the route from re-scheduling as it should. I've been busy with work this week but will try to look into it this weekend and see if I can fix it.

Splitting flight scheduling and operating into two different systems is interesting. I'll have to see what changes I would have to make in order to do that. The issue is calculating the correct dates for arrival and departure, especially several days in advance. Working with time zones, different DST settings, crossing the international date line, all makes scheduling very complicated in the back-end for a real-time system. Routes are created by users in local time, but then I have to convert that to UTC time, and add/subtract days to departure and arrival times. So even if I split the two systems it wouldn't get rid of these issues, but it would probably prevent routes not scheduling due to system lag and such like you said.

[Unknown98]

I too see aircraft in Grey status even though they are assigned a route, it seems to be the last flight rotation in a multiple flight trip that is messing up

Aircraft may take a few mins to sync up and display the correct status. I've seen this as well but it usually sorts itself out.

[dktc]

The issue is calculating the correct dates for arrival and departure, especially several days in advance. Working with time zones, different DST settings, crossing the international date line, all makes scheduling very complicated in the back-end for a real-time system. Routes are created by users in local time, but then I have to convert that to UTC time, and add/subtract days to departure and arrival times.

Understand that this is complicated and appreciate your efforts in ironing out all the issues.

I think to simplify things, you should be storing the times of the routes and flights in UTC / GMT+0 or server time. Whichever it is, it needs to be consistent across.
That means:
- Stored all time in UTC / GMT+0 in routes database.
- When a route gets creates, convert the time to UTC / GMT+0 before storing.
- When a flight gets generated, departure and arrival times are stored in UTC / GMT+0 in the back end, regardless of the origins and destinations.
- GMT time zones get stored per airport, in the airport database. You probably want to separate this into different columns: normal time, DST, DST start date, DST end date, and potentially a DST? boolean.
- When a route or a flight gets displayed, regardless of page, it queries the airport database for airport time zones. Then display the departure and arrival time in local airport times based on that.

This might add to the server load, dependent on what setup you have currently. However, this would definitely solve your issue above. At the same time automates all the required adjustments of flight schedules due to DST, which would happen if times of routes are stored in local time. (Think from a gate use perspective, if flight A use the gate until 40 minutes before flight B, but flight B originates from a DST airport while flight A doesn't. When DST comes in effect, flight B will arrive 20 minutes before flight A is scheduled to depart if departure times are stored in local time, creating problems. Similarly, from a route perspective, in a roundtrip itinerary, if one airport has DST while another doesn't, it could screw up the whole itinerary when DST comes into effect, or comes out of effect, if the plane has less than 1 hour idle on the ground and you store departure time in local time of departure airport. If you store all routes and flights in GMT+0, the local time of the flights will be re-timed automatically when DST comes into and out off effect.)

This also leads to two even more complicated questions down the road: time-padding of itinerary, and flight delays (more specifically, systematic delays related-to DST due to airport slot restrictions). But these don't need to be considered now; not until all the fundamentals are sorted.

[Unknown98]

I already do most of that. Route configurations are stored in local time, and then when I schedule flights from the routes, the flights are stored in UTC. When flight times are displayed on the airport pages or active flights the UTC times are converted back to local times. It would probably simplify things if I stored routes in UTC to begin with, however. I have a list of all countries and their respective DST start/end times, and then each airport is a boolean 1/0 to determine DST participation. I just manually update the DST database every 6 months or so with the new start/end times.


Regarding flights not scheduling I think it has something to do with where your airline is based. I have two test airlines, one in Europe (Croatia) and one based in the US (West Coast). My europe airline has no scheduling issues whatsoever, and my american airline has lots of routes that only get partially scheduled.

[gaff85]

Still seeing greyed out aircraft, these are the same each day, all european based routes

[dktc]

Regarding flights not scheduling I think it has something to do with where your airline is based. I have two test airlines, one in Europe (Croatia) and one based in the US (West Coast). My europe airline has no scheduling issues whatsoever, and my american airline has lots of routes that only get partially scheduled.

From a system point of view, where an airline is based should have no effect on routes/flights scheduling whatsoever, right? I mean technically speaking, it is all a bunch of numerical id's.

And then, flights are scheduled when the aircraft gets turned around after the last leg of the previous flight. In that sense, regardless of where your airline is based, your flights get scheduled around the clock.

The only common factor would be time zones. I would guess that there might be an issue in the time zone conversion codes for anything GMT minus x time zones. If you look into where the routes are left off, you will likely see a pattern in terms or west/east-bound and whether they are related to date-changes, local time or UTC (or perhaps date change based on local time but no date change based on UTC, or vice versa, which could easily trip up the codes since your back end time zones are not consistent).

I still think storing routes in UTC will help solve this problem. It seems like currently some flights are scheduled on the wrong day, which also points to a conversion issue with GMT minus x time zones. (I had a plane scheduling a Friday evening route, on Friday afternoon, for departure flight on Saturday evening, all local time. The route was not supposed to fly on that aircraft on Saturday at all.)

The other thing that would help is to add the denotations of +1 and +2 on route schedules. This could potentially help catch any issue with the conversion algorithm (assuming that it is converting from local to UTC that is the issue, not the converting back which is simply for display at this moment), and also serves as a good reminder to help prevent some user scheduling issues.

Just my two cents.

[dktc]

Some further evidences that there is a time zone conversation issue when flights get scheduled from routes. This relates to the treatment of +1 and +2 during flight scheduling.

Currently I have an aircraft with "in flight" status, "enroute to EWR". It also has a big red "ERROR" for location.
NXX041 Airbus A340-500 Leased 2 70 64 56 20 42,718 16,426 ERROR 100.0% 9.13

On active flights screen, it is currently flying two flights at the same time.
LL 232 MEL — Melbourne EWR — Newark 13:53 (01:53 — 15 Hours 30 Minutes) A340-500 (NXX041)
LL 231 EWR — Newark MEL — Melbourne 07:03 (05:03 — 18 Hours 40 Minutes) A340-500 (NXX041)
Note that this should be the first round trip that this (perhaps the world's longest) route has been scheduled and flown, because it was just set up yesterday and the plane just got transferred into place at EWR in time for the above outbound leg LL 231. That means these two legs are of the same route, same flight, scheduled at the same time, not remainder of a previous flight that somehow got overlapped.

Route schedule wise, outbound depart Wed, Fri, Sun from EWR at 21:20 local time, arriving at MEL 07:03+2, local time.
Inbound leg should then depart Fri, Sun, Tue from MEL at 08:10 local time, arriving at EWR same day at 13:53, local time.
What happened was that the system basically scheduled the outbound of 17/6 and the inbound of 17/6 at the same time. The correct inbound should be scheduled on 19/6 instead, local time.

Similarly, this might be the issue that contributes to the partially scheduled flight, as in the system treat the leg that get left out as something that is already in the past. Say if a flight is generated at 08:00, with a leg that should depart 02:00+1 local time. If the system treats it as 02:00+0, then the leg would simply not get scheduled because it was in the past already. Hence, some routes (always the same one?) get scheduled partially. This might also be related to the international day line conversion, which would explain why the North American test airlines have the issues, but not the European test airlines.
(Come to think of it, this should not be the issue affecting the partially scheduled flights. The system deals with +1 without too much of an issues. Guess it is the +2 that broke the codes...)

Edit 2:

The previously reported "skipping a day" issue with flight schedule might not be due to system lags after all. I am seeing the followings.
Deactivating route, cancelling flights, reactivating the route, yielded the exact same results. I went as far as re-doing the operating days of the route, but still to no avail. Guess we will lump this onto the date issue when flights get generated.

EWR  IST  EWR M T W Th F S Su 23:10 — 22:34 747-200 (NXX020)
LL 213 EWR — Newark IST — Istanbul 06-18 23:10 (06-19 11:10 — 24 Hours 11 Minutes) 747-200 (NXX020)
LL 214 IST — Istanbul EWR — Newark 06-19 18:50 (06-19 23:50 — 36 Hours 51 Minutes) 747-200 (NXX020)

IND MXP IND M T W Th F S Su 23:50 — 23:00 A330-300 (NXX018)
LL 121 IND — Indianapolis MXP — Milan 06-18 23:50 (06-19 11:50 — 24 Hours 41 Minutes) A330-300 (NXX018)
LL 122 MXP — Milan IND — Indianapolis 06-19 19:00 (06-20 01:00 — 37 Hours 51 Minutes) A330-300 (NXX018)

Hope this helps.

[luizdom]

Only the first 2 parts of the route are programmed
GRU > POA > BSB and it's over, do not go to the REC > BSB > GYN >GRU


route=00dec270d257886924e7552f98fb2993

[Jamesthomeson]

Now it appears that certain routes of mine are scheduling entirely as they should when activated, but halfway through they just stop and the other half just unschedules.

[Unknown98]

From a system point of view, where an airline is based should have no effect on routes/flights scheduling whatsoever, right? I mean technically speaking, it is all a bunch of numerical id's.

And then, flights are scheduled when the aircraft gets turned around after the last leg of the previous flight. In that sense, regardless of where your airline is based, your flights get scheduled around the clock.

The only common factor would be time zones. I would guess that there might be an issue in the time zone conversion codes for anything GMT minus x time zones. If you look into where the routes are left off, you will likely see a pattern in terms or west/east-bound and whether they are related to date-changes, local time or UTC (or perhaps date change based on local time but no date change based on UTC, or vice versa, which could easily trip up the codes since your back end time zones are not consistent).

I still think storing routes in UTC will help solve this problem. It seems like currently some flights are scheduled on the wrong day, which also points to a conversion issue with GMT minus x time zones. (I had a plane scheduling a Friday evening route, on Friday afternoon, for departure flight on Saturday evening, all local time. The route was not supposed to fly on that aircraft on Saturday at all.)

The other thing that would help is to add the denotations of +1 and +2 on route schedules. This could potentially help catch any issue with the conversion algorithm (assuming that it is converting from local to UTC that is the issue, not the converting back which is simply for display at this moment), and also serves as a good reminder to help prevent some user scheduling issues.

Just my two cents.

Bad wording on my part, yeah airline base wouldn't have any effect on flight scheduling. But whether the flight departs "today" or "tomorrow" as it relates to UTC would have an effect. My europe flights end and re-schedule around 21:00-23:00 UTC - so they get scheduled for +1 day - but my american flights end and re-schedule around 06:00-08:00 UTC - so they get scheduled for the same day, +0. So possibly something with that could be causing certain flights to mis-schedule or not schedule at all.  

Some further evidences that there is a time zone conversation issue when flights get scheduled from routes. This relates to the treatment of +1 and +2 during flight scheduling.

Currently I have an aircraft with "in flight" status, "enroute to EWR". It also has a big red "ERROR" for location.
NXX041 Airbus A340-500 Leased 2 70 64 56 20 42,718 16,426 ERROR 100.0% 9.13

On active flights screen, it is currently flying two flights at the same time.
LL 232 MEL — Melbourne EWR — Newark 13:53 (01:53 — 15 Hours 30 Minutes) A340-500 (NXX041) 
LL 231 EWR — Newark MEL — Melbourne 07:03 (05:03 — 18 Hours 40 Minutes) A340-500 (NXX041) 
Note that this should be the first round trip that this (perhaps the world's longest) route has been scheduled and flown, because it was just set up yesterday and the plane just got transferred into place at EWR in time for the above outbound leg LL 231. That means these two legs are of the same route, same flight, scheduled at the same time, not remainder of a previous flight that somehow got overlapped.

Route schedule wise, outbound depart Wed, Fri, Sun from EWR at 21:20 local time, arriving at MEL 07:03+2, local time.
Inbound leg should then depart Fri, Sun, Tue from MEL at 08:10 local time, arriving at EWR same day at 13:53, local time.
What happened was that the system basically scheduled the outbound of 17/6 and the inbound of 17/6 at the same time. The correct inbound should be scheduled on 19/6 instead, local time.

Similarly, this might be the issue that contributes to the partially scheduled flight, as in the system treat the leg that get left out as something that is already in the past. Say if a flight is generated at 08:00, with a leg that should depart 02:00+1 local time. If the system treats it as 02:00+0, then the leg would simply not get scheduled because it was in the past already. Hence, some routes (always the same one?) get scheduled partially. This might also be related to the international day line conversion, which would explain why the North American test airlines have the issues, but not the European test airlines.
(Come to think of it, this should not be the issue affecting the partially scheduled flights. The system deals with +1 without too much of an issues. Guess it is the +2 that broke the codes...)

Edit 2:

The previously reported "skipping a day" issue with flight schedule might not be due to system lags after all. I am seeing the followings.
Deactivating route, cancelling flights, reactivating the route, yielded the exact same results. I went as far as re-doing the operating days of the route, but still to no avail. Guess we will lump this onto the date issue when flights get generated.

EWR  IST  EWR M T W Th F S Su 23:10 — 22:34 747-200 (NXX020)
LL 213 EWR — Newark IST — Istanbul 06-18 23:10 (06-19 11:10 — 24 Hours 11 Minutes) 747-200 (NXX020)
LL 214 IST — Istanbul EWR — Newark 06-19 18:50 (06-19 23:50 — 36 Hours 51 Minutes) 747-200 (NXX020) 

IND  MXP  IND M T W Th F S Su 23:50 — 23:00 A330-300 (NXX018)
LL 121 IND — Indianapolis MXP — Milan 06-18 23:50 (06-19 11:50 — 24 Hours 41 Minutes) A330-300 (NXX018)
LL 122 MXP — Milan IND — Indianapolis 06-19 19:00 (06-20 01:00 — 37 Hours 51 Minutes) A330-300 (NXX018)

Hope this helps.

I think I will change the routes to store the departure time in UTC rather than local. Then all the calculations can be done during route creation as opposed to route scheduling. Might actually help speed up the scheduling script as well if I do that. Then on route creation we can display +1, +2, etc for each flight. Then just store that in the DB, and use that to hard-code in the departure days during scheduling rather than trying to calculate it on the fly. 

The only issue I see - and the reason I stored routes in local times to begin with - is the DST switchover. If you have a route that departs at say 5am, and then DST ends - that route will now be departing at 4am. And the way the demand formula works you might lose some demand for having such an early departure. But it's either that or continue trying to fix the system we have now, which obviously has some issues.