General coding rules for schedules

Timesheet order of priorities

There is no explicit "priority indicator" attribute for a Timesheet. However, there exists a natural order of priorities that shall be applied when Timesheet are interpreted, based on:

• the day attribute, where the values shall be interpreted in the following order of priorities (values that are first in the list overrule values that are later in the list): 'HOL', 'BEF_HOL', 'AFT_HOL', 'WORK_DAY', 'BEF_WORK_DAY', 'AFT_WORK_DAY', 'BUSY_FRI', 'MON', 'TUE', 'WED', 'THU', 'FRI', 'SAT', 'SUN', 'ANY'
• the excluded attribute, where Timesheet that are have excluded="YES" take precedence over other Timesheet.

If two or more non-excluded timesheets refer to the same date, day and/or time period, then the resulting time period shall be derived by applying the order of priority rules.

Properties with constant value do not need 'H24'

For a property or a group of properties that may have an associated schedule (the class that contains the properties is derived from PropertiesWithSchedule), when their value does not actually change according to a schedule, then it is not necessary to associate a 'H24 Timesheet'. For example, if an airspace is active H24, it can be coded as a single AirspaceActivation object with status='ACTIVE' and no associated timeInterval.Timesheet. However, this is not a strict rule as the current AIS practice is to explicitly indicate 'H24' for properties that are significant operationally, such as the activation hours or the working hours.

Time intervals - interpretation

According to the AIXM Temporality Concept version 1.1, time intervals in AIXM are considered to include the start time instance of the interval and exclude the end time instance of the interval. This interpretation deviates from the provisions of the ISO 19108 standard, which is part of the ISO series of standards that includes the GML Schema definition and is used as a basis for the definition of the AIXM 5.1 schema. However, this deviation is justified by the current aeronautical information practices and by the fact that all known digital AIS systems apply the convention stated above.

For example:

• when only dates are considered in the definition of a time interval - if a route is established starting with a certain date, a query on that date for 'valid routes' is expected to retrieve that route instance.
  
  • on the contrary, if a route is withdrawn on a certain date, a query on that date for 'valid routes' is expected to no longer retrieve that route instance;
• the same is applied when dates and times are used - if an obstacle is announced to exist from 09:00 till 17:00 UTC on specific date, then a query asking for 'valid obstacles at 09:00 UTC' is expected to retrieve that obstacle instance.
  
  • on the contrary, a query asking for 'valid obstacles at 17:00 UTC' is expected to no longer retrieve that obstacle instance.

"End of day" time value

Taking into consideration the rule for time intervals discussed above, any value different from 24:00(:00) or 00:00(:00) would leave a gap that can range from 1 minute to a fraction of a second (depending on the number of digits used). For example, if "23:59" is used as 'end of day' value, then the time interval from 23:59:00 until 23:59:59,9999..." is not included. Therefore, either '24:00' or '00:00' should be used as 'end of day' value.

ICAO Annex 5 attachment E indicates that “Hours should be represented by two digits from 00 to 23”, which implicitly excludes the use of “24:00”. This is consistent with the PANS-AIM rules for NOTAM, which explicitly indicates that ‘The end of a day shall be indicated by “2359” (i.e. do not use “2400”)’. However, Annex 10, Vol II, para 3.4.1 says that ‘coordinated universal time UTC should be used by all stations in the Aeronautical… Midnight shall be designated as 2400 for the end of the day and as 0000 for the beginning of the day", which seems to be a deviation from the Annex 5 provisions. Also, many AIP use "2400" as end of the day format for schedules.

The ICAO Annex 15 refers in § 1.2.3.1 to the ISO 8601 International Standard for “Data elements and interchange formats — Information interchange — Representation of dates and times”. The currently published version 8601:2004 allows hour values from 0 to 24:00. However, this will be changed in the new version of the standard as the Draft 8601-1 (2016) amendment proposed to remove the “24” from the allowed values for hours.

Considering all the elements listed above, it seems that avoiding the use of 24:00 as time value would be the logical conclusion for the AIXM data coding rules. A general coding rule requires that the endTime value is higher than the startTime value when they both occur on the same day (dayTil is empty). Therefore, '00:00 of the next day' should be used as 'end of day' value in Timesheet.endTime. This is similar to the decision to use "00:00:00" of the next day as end of TimeSlice validity (see AIXM Temporality Concept version 1.1, para 4.4.1).

In order to remain compliant with the ICAO Annex 15 requirements for NOTAM format (item C in particular), this shall be translated into "2359 of the previous day (date)" when the NOTAM is generated automatically.

The following examples indicate how this rules is applied in some particular cases:

HMI recommendations

Some schedules may be relatively complex and this may lead to difficulties for the operator when trying to get the global picture of what is being encoded. Based on the experience gathered in this area through trials and previous projects, it is recommended that the HMI for schedules encoding enables both:

• "forms based" input - where the operator enters values in predefined fields, and
• "text based" input - where the operator types directly a textual description of the schedules and the application automatically decodes that into structured data; the text based input is expected to be used for simpler but frequently used schedules;

When the form based input is used, the application should generate a text based description of the schedule in real time, in the form that it would appear in a NOTAM item D or E. This would give confidence to the operator that the schedule was correctly encoded.