According to the contest write-up predicted runway arrival and gate arrival times are to be expressed as minutes past midnight. My question is which midnight is applicable if a flight spans more than one day?

If a flight is scheduled to arrive on the runway on 2Dec at 23:40 and I predict a five minute delay and it will arrive at 2Dec at 23:45, then I understand my prediction will be 1425 minutes past midnight.

However, if predict a 30 minute delay where the above flight will arrive on 3Dec at 00:10, then I assume I'll submit 10.

Is this a correct interpretation of the requirement?

Good question! We're sorry for the confusion.

The process and form of submission will be clarified better with the next data release, but let me answer now also: It'll be the number of minutes past the midnight that started the day that the flight was selected as being in the air. So your 10 minutes should really be 1450 minutes.

This is still not clear. The wiki states that cutoff time may be selected between 9am EST and 9pm EST, which translates to 2pm UTC and 2am UTC. Although the leaderboard cutoff times don't have times past midnight UTC, I suppose the final test cases might have.

Consider the following case: a flight with published/scheduled/actual gate departure of Dec 09, 23:50 UTC, and actual runway departure ("in the air") of Dec 10, 00:10 UTC, and cutoff time, let's say, Dec 10, 01:00 UTC. The model predicts arrival at Dec 10, 02:00 UTC - should it output 120 or 1560 ?

The predictions you are making are always within the context of a specific cutoff time on a specific day (for example, 8:47PM UTC on December 5). The submissions should always be in minutes since midnight UTC at the start of this corresponding day (as specified by the folder name / cutoff time), even if the flight lands >24 hours after this.

Thus, for your specific question, the model should output 1560 (not 120).

Hi, Ben!  Thank you for your reply.  So I am understanding the cut off time between Dec 9 2:00PM UTC and Dec 10 2:00AM UTC should all be counted in Dec 9, is that correct?

Thx again.

It seems the code in the github repository uses the day of the cutoff time not the selected "day" (line 323 https://github.com/benhamner/GEFlightQuest/blob/master/PythonModule/geflight/transform/flighthistory.py#L323). To agree with this code the model should output 120, correct? Is the code for generating solutions incorrect?

I agree, the code in github seems to contradict what the admins are saying here on the forum.

To admins: please double-check this issue, as it may introduce 24-hour error to final results of the users who followed what you've said in the forum (myself included). This doesn't affect leaderboard data, as there are no cutoff times past midnight UTC there.

Thank you.

New to the contest, and bumping this to see if we got a resolution.  My apologizes if it was addressed in another thread.

The code I pulled from github last night still shows the soluion generating # of minutes past midnight on the day of the cutoff (not midnight on the flight day to which the cutoff applies).   

Will cutoffs for the test set range up to 2:00 AM next day UTC?  If so, is it still the case that we should express arrival and departure times as number of minutes after midnight of the flight day (i.e, valid values can be over 1440).

Thanks!

Why this complication with the number of minutes int he first place? Cannot we just submit exact instant in UTC time?

The benchmarks on github page are computing the prediction w/respect to cutoff day and not w/respect to  the actual split day. For example, if the cutoff for day 2012-12-02 were 2012-12-03 01:00:00+00:00, then the number of minutes would have been computed since the midnight of 2012-12-03 and not since the midnight of 2012-12-02 as it is now.

Ben, could you please confirm that this is intended.

Ben,

You said that "The submissions should always be in minutes since midnight UTC at the start of this corresponding day (as specified by the folder name / cutoff time), even if the flight lands >24 hours after this."

In fact, however, if a cutoff time passes the UTC midnight (it can happen), the minutes numbers based on the folder name will be different these based on the cutoff time. Therefore, folder-name-based and cutoff-time-based midnights are different at some times. It is neccessry to clarity the definition of midnight. 

Midnight is according to the folder-name-based midnight.

Hi Ben.

I think that prediction horizon of 26,459 rows is very difficult to obtain.  

In my experience,  next  5,000-5,200  rows  are  accurate.