Page Comparison

H24

(continuous service, 24/7)

A single Timesheet:

• timeReference=('UTC')
• dailightSavingAdjust='NO' or nilReason='inapplicable'
• day='ANY'
• dayTil='ANY'
• startTime='00:00'
• endTime='00:00'
• excluded = 'NO'

According to the AIXM rules for PropertiesWithSchedule, a property that has a constant value (such as an AirspaceLayerClass that does not change according to a schedule) does not need a schedule to be coded. However, some data providers might considers necessary to give an explicit indication that the service or facility is explicitly provided H24, by coding a "H24 schedule"

HJ

(sunrise to sunset)

A single Timesheet with:

• timeReference=('UTC')
• dailightSavingAdjust='NO' or nilReason='inapplicable'
• day='ANY'
• startEvent='SR'
• endEvent='SS'
• excluded = 'NO'

It is assumed that HJ means 'sunrise to sunset'. If HJ actually means 'sunrise minus xx minutes' to 'sunset plus xx minutes', then the additional minutes should be coded as startTimeRelativeEvent and endTimeRelativeEvent respectively.

For States that apply the "SERA Regulation" (European Union Commission Implementing Regulation (EU) No 923/2012), ‘night’ might actually mean "the hours between the end of evening civil twilight and the beginning of morning civil twilight. Civil twilight ends in the evening when the centre of the sun’s disc is 6 degrees below the horizon and begins in the morning when the centre of the sun’s disc is 6 degrees below the horizon." In this case, different values should be use for start/end event:

• startEvent='OTHER:START_MORNING_CIVIL_TWILIGHT'
• endEvent='OTHER:END_EVENING_CIVIL_TWILIGHT'

HN

A single Timesheet with:

• timeReference=('UTC')
• dailightSavingAdjust='NO' or nilReason='inapplicable'
• day='ANY'
• dayTil='ANY'
• startEvent='SS'
• endEvent='SR'
• excluded = 'NO'

It is assumed that HN means 'sunset to sunrise'. If HN actually means 'sunset plus xx minutes' to 'sunrise minus xx minutes', then the additional minutes should be coded as startTimeRelativeEvent and endTimeRelativeEvent respectively.

For States that apply the "SERA Regulation\'",different values should be used for start/end event:

• startEvent='OTHER:END_EVENING_CIVIL_TWILIGHT'
• endEvent='OTHER:START_MORNING_CIVIL_TWILIGHT'

HX

(no specific working hours)

No Timesheet.

Use an associated Note with propertyName = 'timeInterval', purpose = 'DESCRIPTION' and note='HX (no specific working hours)'

HO

(service available to meet operational requests)

No Timesheet.

NOTAM

(activity periods to be published by NOTAM)

No Timesheet.

[TS] and [/TS]

All the elements that appear between [TS] and [/TS] are encoded as a single timesheet

start date

Timesheet.startDate

end date

Timesheet.endDate

start time

Encoded as Timesheet.startTime

start event

Encoded as Timesheet.startEvent

rel. start

Encoded as Timesheet.startTimeRelativeEvent

Positive values indicate that the actual start time is after the event.

switch

Encoded as startTimeRelativeEvent

Indicates which one takes precedence between the start/end time and the start/end event (including the eventual time relative to the event)

end time

Encoded as Timesheet.endTime

end event

Encoded as Timesheet.endEvent

rel. end

Encoded as Timesheet.sendTimeRelativeEvent

Positive values indicate that the actual end time is after the event.

note

Encoded as Timesheet.annotation

Examples of such notes:
"Departures till 2000 LT. However, latest ready time (with explanation of what that implies) is then often 15 minutes earlier or the departure"

excluded date

Each excluded date is coded as a separate Timesheet with excluded='YES', startDate equal the "excluded date", endDate equal to "excluded date +1 day", day='ANY', dayTill='ANY', startTime='00:00', endTime='00:00', timeReference='UTC+/-X' (local time as UTC zone).

schedule note

Encoded as Note associated with the class that owns the schedule, with propertyName='timeInterval' and purpose='REMARK'.

[TS] and [/TS]

start date

Timesheet.startDate

end date

Timesheet.endDate

on weekday

Encoded as Timesheet.day

Any weekday values is allowed, including HOL

from weekday

Encoded as Timesheet.day

Any weekday values is allowed, including HOL

to weekday

Encoded as Timesheet.dayTil

Any weekday values is allowed, including HOL

start time

Encoded as Timesheet.startTime

start event

Encoded as Timesheet.startEvent

rel. start

Encoded as Timesheet.startTimeRelativeEvent

Positive values indicate that the actual start time is after the event.

switch

Encoded as startTimeRelativeEvent

Indicates which one takes precedence between the start/end time and the start/end event (including the eventual time relative to the event)

end time

Encoded as Timesheet.endTime

end event

Encoded as Timesheet.endEvent

rel. end

Encoded as Timesheet.endTimeRelativeEvent

Positive values indicate that the actual end time is after the event.

note

Encoded as Timesheet.annotation

Examples of such notes:
"Departures till 2000 LT. However, latest ready time (with explanation of what that implies) is then often 15 minutes earlier or the departure"

excluded date

Each excluded date is coded as a separate Timesheet with excluded='YES', startDate equal the "excluded date", endDate equal to "excluded date +1 day", day='ANY', dayTil='ANY', startTime='00:00', endTime='00:00', timeReference='UTC+/-X' (local time as UTC zone).

excluded day

Encoded as a separate Timesheet with excluded='YES', day equal to the "excluded day" value, startTime='00:00', dayTil equal to the "next day after the excluded day" value, endTime='00:00', timeReference='UTC+/-XX' (local time expressed as an as UTC zone).

It does not make sense to use the normal days of the week in this case, only 'HOL', 'BEF_HOL', 'AFT_HOL', 'WORK_DAY', 'BEF_WORK_DAY', 'AFT_WORK_DAY', 'BUSY_FRI' make sense here

schedule note

Encoded as Note associated with the class that owns the schedule, with propertyName='timeInterval' and purpose='REMARK'.