Flights not scheduling or flying

[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.