Calendaring and Scheduling with XML-RDF

1. Orlando - A Logical Mnemonic Model for Calendaring and Scheduling

Latest version http://www.skical.org/orlando.html

1.1. The Concept of Universal Synchronization

Any resource or directory of resources, where temporal-spatial considerations are of significance for the resource, or to the human or electronic agent seeking to know about or utilize the resource, will publish, in a machine-readable format, the temporal-spatial coordinates of that resource.

Any person or person's electronic agent wishing to know about, use, or negotiate the use of a resource will have the option of declaring in a machine-readable format any of their own temporal-spatial coordinates that might serve to optimize possible transactions.

Any person or person's electronic agent wishing to interact with any other person or their electronic agent may optimize that interaction through publishing, in a machine-readable format, the temporal-spatial coordinates that might add value to that interaction

Without debating the feasibility, utility or desirability of Universal Synchronization, this paper will present the Orlando model for representing temporal coordinates in a machine-readable format that utilizes the mnemonics of the common calendar and wall clock.

1.2. Introduction

We have inherited a calendar system, the Gregorian, which incorporates a few thousand years of trying to suitably mesh the cycles of heavenly bodies and their effects on earth and its inhabitants. Unfortunately there are not exactly 360 days in a year composed of twelve 30-day months. Unfortunately the moon does not complete its cycle exactly 12 times a year. Unfortunately the earth does not rotate or wobble at a constant speed.

A significant portion of humanity has agreed on the units of the Gregorian calendar and the 24-hour day as our datetime model, while the scientific community has worked out timekeeping systems more compliant within their specific domains. A significant portion of the world gets by just fine on the mean accuracy of a wristwatch, while the scientific community demands a higher level of precision.

Computers don't need the mnemonic datetime units. If you were designing the datetime system of a computer you would probably opt for calculating dates and times internally in the scientific way, i.e. you would restrict yourself to counting standard days of standard seconds. But if humans were expected to transfer temporal information in and out of your computer system you would map your internal representation into that which is datetime mnemonic for humans.

We're in the midst of the mnemonic code era - witness XML. Look around at any of the datetime schema formats currently under discussion in the Internet community, such as the datetime types of XML-Schemas, and you will find mnemonic representations of dates and times.

Well look again and you will see that this is only partially true. We have actually settled on semi-mnemonic representations. We have created 2 points of conversion; from mnemonic to semi-mnemonic, and then again from semi-mnemonic to scientific. From "Quarter to Seven on the 24th of September, '01", to "2001-09-24T18:45:00Z", to "MJD2452177.23965".

The middle step above is in ISO8601 extended representation as used in XML Schemas Part Two Datatypes. ISO8601 big-endian representation, ordering from left to right (from most significant to most precise) is the base for all modern semi-mnemonic temporal representation. ISO8601 has had significant impact, and the recent minor revision, ISO8601-2000(E) has taken a step towards standardizing reoccurrences.

If we are going attain any of the interoperability of Universal Synchronization, where the temporal-spatial coordinates of businesses, stores, services, work shifts, academic courses, transport schedules, entertainment and media become an integrated component of universally machine-understandable resource description, we will need to agree on effective models for the representation, storage and querying of reoccurrences. It seems reasonable that any such model should be optimized for and by the natural rhythms of everyday human planning and scheduling, as reflected in the common datetime units and their natural reoccurrences. In this paper we will try to capture the nature of these reoccurrences in a logical and mnemonic model.

1.3. Using mnemonic datetime representation

You can program a machine to do repetitive things at very erratic intervals. The SMIL 2.0 Timing and Synchronization Module, which has little need for datetime unit symmetry, is an example of this, but datetime symmetric loops are very convenient for people. And equally important, datetime units reflect usage.

The Orlando model incorporates the common date-date units of everyday scheduling. The accent is on reoccurrences of a more persistent nature, such as the opening and operating hours of businesses and services, but singular events may also be declared using this model. The ultimate use-case is that in which all human digiphernalia can access and interact (voluntarily - one hopes) with the temporal-spatial coordinates of all possible resources.

Orlando both reformulates and extends the reoccurrence rules of RFC2445, the iCal Calendaring and Scheduling standard that is predominate (at the time of this writing) for mainstream computer based calendaring and scheduling systems. Like RFC2455, XML Schema Datatypes, and other standards work dealing with the representation of time, Orlando uses the datetime terms and representations standardized in ISO8601.

Orlando also defines types which ISO8601 does not cover. ISO8601 does not attempt to standardize the use of named datetime units; the days of the weeks and months; Monday to Sunday and January to February. No doubt internationalization issues are involved in that decision. We will use English datetime units here, assuming these to have equivalents in any modern language.

Note: The latest publication from ISO, ISO 8601-2000(E) Section 5.6.1 introduces a simplified set or recurrence rules, the definitions of which are abbreviated below as:

ISO 8601-2000(E) Recurrence Rules (abbreviated)

1. An interval and a number of recurrences (optional)

2. A duration and a number of recurrences (optional)

3. A duration, a start and a number of recurrences (optional)

4. A duration, an end and a number of recurrences (optional)

The above rules should be seen as a recognition of the need for standardization rather than a full fledged attempt to create a definitive standard for recurring events and persistent scheduling.

1.3.1. Homogeneous temporal states

Orlando deals only in homogeneous temporal states - a constant state that holds throughout the interval, such as "the light is on". If one wanted to say that the light was on during a certain interval of time this could be represented as below:

ON(Light,t)

The negation of ON is OFF. So one could indicate the state of OFF by either negating ON or negating the interval t. One could say that the "(light is not on) during the interval t" or that the "(light is on) not during the interval t". Observe that we are saying nothing about the state of the light outside of the interval t. We could do that by saying "(the light is on) except during the interval t".

Of course the predicate need not be "0N". It can be any set of opposites; true/ false, operating/not-operating, in/out, accessible/not accessible, open/closed etc., as long as the binarity of these states is temporally homogeneous.

3.1.1. Dynamic states

The light in our example could be on, yet growing dimmer during the interval t, and one might choose to represent that as a temporal process of dynamic change. Homogenous states appear to be blunt tools in such cases.

Take a predicate like congested traffic; Congested-Traffic(Highway 7,t). You might want to quantify Congested-Traffic at measurable levels of comparison like Terrible-Congestion, Average-Congestion, Minimal-Congestion and assign each to a homogenous temporal state, as in Terrible-Congestion, t₁ Average-Congestion t₂ Minimal-Congestion t₃ but this could make for lengthy representations. A better approach might be to temporally graph the ebbs and tides of traffic congestion and make the existence of the temporal graph a homogeneous state.

From here on in we will consider the predicate of all Orlando examples to be "VALID" and its negation "NOT-VALID" and we will normally not bother to use subjects like "what is open?" in the examples. We will just focus on the interval t.

1.4. Elements

The Orlando model is comprised of elements and operators. All dates and times will be represented as the values of elements based on natural language datetime units.

There are three types of datetime elements; reoccurring, ordinal and anchored.

1.4.1. Reoccurring datetime elements

A reoccurring datetime element has the following format

ElementName  [ alternate_cycle ] ["^"](" DateTimeValue ")"

t is a universe - the universal set of all time. t is an infinite set. t is also a powerset - the subsets of which are time-intervals demarcated by the datetime value-types of the civil calendar and clock. t is all months and all days and all years and all seconds.

t is the powerset of all datetime value types. But rather than include every possible value-type for every set t, we will consider them by default as members of the set.

For example, if the value type "yMonth" is not explicitly included in the set, it will be included implicitly and the set will contain all months. The following two sets are equivalent. They both hold for all Mondays.

wDay(Mo)

(wDay(Mo) AND yMonth(Jan,Feb,Mar,Apr,May,Jun,Jul,Aug.Sep,Oct.Nov,Dec))

If we desire to limit the set of all possible months to only one month, say January, then we will intersect (logically AND) the set of January with the set of all-possible-months. But in Orlando we don't need to restate all possible months since they are already implied as demonstrated above. The following example is a set of all Januarys, forever:

yMonth(Jan)

Each subsequent explicit addition of a datetime element through conjunction will have the same effect of limiting the set. So to get all the Mondays in all Januarys we will intersect two elements as follows

yMonth(Jan) AND wDay(Mo)

To get all the hours beginning at 9 and ending at 5, for all Mondays, in all Januarys, we will intersect the appropriate datetime sets as follows:

yMonth(Jan) AND wDay(Mo) AND Hour(9/5)

The Venn diagram illustrates the above example.

The following table shows the most common datetime units and their natural cycles.

Table 1: Common reoccurring datetime unit elements

DateTime Unit	Name	Natural cycle
Minute Second	Sec	60 / minute
Hour Minute	Min	60 / hour
Day Hour	Hour	24 / day
Week Day	wDay	7 / week
Months Day	mDay	28 - 31 / month
Year Day	yDay	365 -366 / year
Month Week	mWeek	4 / month
Year Week	yWeek	52 - 53 / year
Year Month	yMonth	12 / year
Quarter	Quarter	4 / year

The following table shows the less common datetime unit elements and their natural cycles.

Table 2: Less common reoccurring datetime unit elements

DateTime Unit	Name	Natural cycle
Picosecond	picoSec	1,000,000,000 / second
Microsecond	microSec	1,000,000 / second
Millisecond	milliSec	1,000 / second
Decadal Year	dYear	10 / Century
Century Year	cYear	10 / millennium
Millennium Year	mYear	none

1.4.2. Epoch-anchored datetime elements

An epoch anchored datetime element has the following format

ElementName  "(" DateTimeValue ")"

As visualized above in Fig 1, each added element contributed towards limiting the set. The set no longer contains all hours and all days and months, only the conjunction of those explicitly declared. Yet each individual element in these sets is still infinite, since these datetime units repeat themselves in cycles indefinitely and the intersections they create are therefore also infinite. The only way to tie-down these sets is by intersecting them with elements that do not repeat themselves.

In the following examples we will use the element Greg, the value of which represents a date anchored to the Gregorian Epoch. Greg(2001) represents the two thousand and first year of the common era. Greg(2001) is the year of this particular conference. Perhaps the year 2001 is the beginning of the XML era whose end is yet in site.

The universal t can be made half-infinite by using the value terms SINCE and UNTIL as in:

Greg(2001//SINCE)

So from this year and indefinitely onward XML reigns supreme.

Before there was XML there were meetings of the Hodgepodge Club on Mondays

Greg(2001/UNTIL) and Hour(9/17) AND wDay(Mo)

the Hodgepodge Club met on all Mondays, between the hours of 9 and 17, up until January 1, 2001 when the Club disbanded.

Or the universe can be closed at both ends. The following are both equivalently binding the Monday meetings of the Daughters of the Hodgepodge Club to the year 2002:

Greg(2002) AND Hour(9/17) AND wDay(Mo)

Greg(2002//SINCE) AND Hour(9/17) AND wDay(Mo) AND Greg(2002//UNTIL)

...representing all Mondays, between the hours of 9 and 17, from January 1, 2002 up until the beginning of January 1, 2003

Left by themselves, the elements ranging from seconds to years will never anchor to an epoch-based Calendar date. An epoch-based calendar element must be intersected into the t universe. Though we often use the Gregorian calendar system, any epoch anchored system will do. Keep in mind though that to get from one epoch anchored system to another, you will usually need a map. The next example uses the Modified Julian Date Element MJD...

MJD(48987/49352) AND yMonth(Jan) AND wDay(Mo) AND Hour(5/8)

...giving us all the hours between 5 and 8, in all Mondays in January for all days from 48,987 up until 49,352, as measured in Modified Julian Date days. This is the equivalent to the Gregorian year of 1993.

Table 3: Anchored Datetime Elements

Datetime unit	Name	Natural cycle
Gregorian	Greg	none
Julian Date	JD	none
Modified Julian Date	MJD	none
Network Time Protocol	NTP	none

1.4.3. Ordinal datetime elements

An ordinal datetime element has the following format

ElementName  "(" DateTimeValue ")"

An interesting aspect of the datetime-unit elements is that their spatial relationships to each other are rigid. You can not move Monday closer to Wednesday, or the third week of the year further away from the 17th week of the year, anymore than you can, when driving from Copenhagen to Rome, stop in Innsbruck after 50 kilometers. Spatially those cities are where they are- and temporally so are January and March.

In Orlando we deal with three types of datetime values; Those that are bound by anchoring to an epoch, such as in the Gregorian element, Greg. Those that are bound by reoccurrence, such as the month element - yMonth, and those that are neither bound or anchored at all. We call this last type ordinal datetime value types.

Ordinal datetime-value types are special in the sense that they only exist in some netherworld until they can be related to one of the bound datetime value types.

You can make statements about 10 days or you can declare one month or even designate 1,000,000 years to float around in our universe of time, but you may never find them again.

To understand this further look at the example below. It is simply 9 till five on Monday in some year whenever. We have no idea which year this is.

Year(1) AND Hour(9/17) AND wDay(Mo)

Adding more years will not help.

((Year(1/200000) AND Hour(9/17) AND wDay(Mo)) AND Day(2)

We are still lost in the woods. To deal with ordinal datetime value elements, logical operators are not enough. We need to establish a temporal relationship between ordinals, anchors and reoccurring elements.

The following table lists the ordinal elements. They are signified either by an anteceding "o" character or in the case of days, weeks, months and years, by either an anteceding "o" or just simply their names.

The distinguishing feature of ordinal elements is that they a) are not anchored b) have no natural reoccurrence cycle c) do not reoccur unless preceded by a P-duration reoccurrence designator.

Table 4: Ordinal datetime unit Elements

DateTime Unit	Name	Natural cycle
Ordinal Second	oSec	none
Ordinal Minute	oMin	none
Ordinal Hour	oHour	none
Ordinal Day	Day alt. (oDay)	none
Ordinal Week	Week alt. (oWeek)	none
Ordinal Month	Month alt. (oMonth)	none
Ordinal Year	Year alt. (oYear)	none

1.4.4. Functional elements

Table 5: Functional Elements

Functional elements	Name	Natural cycle
Offset	OFFSET	none
By Set position	SETPOS	none
Number of occurrences	OCCURS	none
TimeState	TIMESTATE	none
Datetime variable	VAR	none

Five elements; OFFSET, SETPOS, OCCURS, TIMESTATE and VAR can be ANDed or ORed to the datetime elements.

4.4.1. OFFSET

The OFFSET element has the following format

OFFSET "(" P-DURATION ")" 

Entire sets of datetime values or datetime variables can be shifted by some interval backward or forwards by the value of ISO8601 P-durations. In the example below the interval from 3:45 am to 5:15am will occur instead between 2:45am and 4:15am..

In the example below the first intersection would be carried out and result in a period of time between 3:45am and 4am and then this value would be offset to an interval between 2:45am and 3am

(Hours(3) AND Hours(3:45//5:15)) AND OFFSET(-P1H)

Elsewhere in this paper, we have DECLARED the interval when Swedish daylight saving time is in force. The value is contained in a variable named SwedDST Now if we declare US DST as follows:

DECLARE usDST (yMonth(Apr) AND mDay(1Su)) DURING (yMonth(Oct) AND mDay(-1Su))

We can use both to indicate the period when Swedish and US DST are not in sync.

VAR(SwedDST) AND VAR(usDST) OFFSET(+P1H)

In the example below OFFSET gives us another solution to the Election Day Problem.

Greg(2008/UNTIL) STARTS YearP4Y(2) AND ((mDay(1Mo) AND yMonth(Nov)) AND OFFSET(P1D)) - which is the equivalent to the following...

Greg(2008/UNTIL) STARTS YearP4Y(2) AND (mDay(2//9) AND wDay(Tu) AND yMonth(Nov))

Note that an OFFSET can be both ORed or ANDed so while an ANDed OFFSET would move both the beginning and end of an interval, an ORed Offset would increase or decrease the size of the interval by moving either the end or the beginning.

Greg(2020) AND OFFSET(P1Y)) - returns Greg(2021) while as...

Greg(2020) OR OFFSET(P1Y)) - returns Greg(2021//2022)

4.4.2. SETPOS

The SETPOS element has the following format

 SETPOS "(" [-] FLOAT ")" 

The SETPOS element is a direct descendant of the RFC2445 BYSETPOS. SETPOS identifies a member of a set by its ordinal position. When the values of one or more elements are matched with a calendar, a new set is derived. Then, the positional ordering of that new set is queried. If for example a set comprised of the last weekdays of the month is intersected with a particular month such as June 2010, a set of the monthdays in June 2010 that match the last occurrences of the weekdays will be returned. Then the temporal ordering of that new set will be counted, either from the beginning or the end of the set.

For example the 2nd to last weekday of the month shown first in RFC2445-, and then in Orlando format:

DTSTART;TZID=US-Eastern:19970929T090000 RRULE:FREQ=MONTHLY;BYDAY=MO,TU,WE,TH,FR;BYSETPOS=-2

Greg(1997-09-29//UNTIL) AND (mDay(-1Mo,-1Tu,-1We,-1Th,-1Fr) AND SETPOS(-2)

==> (1997 9:00 AM EDT)September 29 (1997 9:00 AM EST)October 30;November 27;December 30 (1998 9:00 AM EST)January 29;February 26;March 30 ...

The 3rd instance into the month of one of Tuesday, Wednesday or Thursday, for the next 3 months:

DTSTART;TZID=US-Eastern:19970904T090000 RRULE:FREQ=MONTHLY;COUNT=3;BYDAY=TU,WE,TH;BYSETPOS=3

Greg(1997-09-04//p3M ) AND (mDay(1Tu,1We,1Th) SETPOS(3)

==> (1997 9:00 AM EDT)September 4;October 7 (1997 9:00 AM EST)November 6

4.4.3. OCCURS

The OCCURS element has the following format

OCCURS "("  FLOAT ")"

OCCURS is the direct descendent of RFC2445 COUNT. It is used to limit occurrences and in this sense it performs the same function as the declared end of any constraining interval. But there is an essential difference between constraint by COUNT and constraint by datetime limit that is similar to the period-implicit / duration-implicit choice. Are we more interested in defining the number of occurrences or the time period they occur in?

For example lets say a course was scheduled to occur on eight consecutive Tuesdays, but one of these Tuesdays was a holiday and no course is to be held on holidays. If we set the constraining factor by the intersection of wDay(Tu) AND yMonth(Apr//P8W) and a holiday happens to fall on one of those Tuesdays, , there will be only 7 occurrences. If we set the constraining factor by OCCURS(8) AND wDay(Tu) then we will have 8 occurrences but it will take nine weeks for them to happen within.

If both OCCURS and a Period limit of one sort or another appear in the same set, then it is the rules of intersection (AND) and union (OR) that govern the outcome. In the first of the following examples, if one the 16 Mondays were to fall on the 15th of May, there would only be 15 occurrences. In the second example, there would be 16 occurrences in any event even if they took 17 weeks to occur in.

yMonth(5//P16W) AND yMonth^(05-15) AND wDay(Mo) COUNT(16)

Greg(2210//P16W) OR wDay(Mo) COUNT(16)

Here are some examples from RFC 2445, given first in iCal notation and then in two possible variations (with and without OCCURS) in Orlando notation.

Every other week on Tuesday and Thursday, for 8 occurrences:

DTSTART;TZID=US-Eastern:19970902T090000 RRULE:FREQ=WEEKLY;INTERVAL=2;COUNT=8;WKST=SU;BYDAY=TU,TH

Greg(1997-09-02//P16W) wDayP2W(Tu,Th) AND Hour(9)

Greg(1997-09-02//UNTIL) wDayP2W(Tu,Th) AND (Hour(9)OCCURS(8))

==> (1997 9:00 AM EDT)September 2,4,16,18,30;October 2,14,16

Every 18 months on the 10th thru 15th of the month for 10 occurrences:

DTSTART;TZID=US-Eastern:19970910T090000 RRULE:FREQ=MONTHLY;INTERVAL=18;COUNT=10;BYMONTHDAY=10,11,12,13,14, 15

Greg(1997-09-10//UNTIL) STARTS DayP18M(10//15) AND (Hour(9) OCCURS(10))

==> (1997 9:00 AM EDT)September 10,11,12,13,14,15 (1999 9:00 AM EST)March 10,11,12,13 Every Tuesday, every other month:

4.4.4. TIMESTATE

The TIMESTATE element has the following format

ElementName "(" TimeStateValue ")"

TimeStateValue ( ALLTIME | NOTIME )

Elements can also be used as binary truth conditionals, by holding the values t or ^t. Though any reoccurring element could express t by including all of its members in a set, or ^t. by being empty eg. yWeek() Orlando defines a specific datetime element called TIMESTATE for this purpose.

In order to express binary homogeneous temporal states, TIMESTATE may have one of two values; NOTIME AND ALLTIME. viz. TIMESTATE(ALLTIME) and TIMESTATE(NOTIME). In the examples below, any other elements being ANDed with TIMESTATE(ALLTIME) will be logically ANDed with themselves. Any other elements being logically ORed with TIMESTATE(ALLTIME) will loose their particular values and become ALLTIME

TIMESTATE(ALLTIME) AND yWeek(5) - the fifth week of the year

TIMESTATE(ALLTIME) AND yDay(200) - The 200th day of the year

TIMESTATE(ALLTIME) OR yDay(200)- Alltime

TIMESTATE(ALLTIME) OR mWeek(2)- Alltime

When TIMESTATE(NOTIME) is logically ANDed with other elements in a set, the set value will be NOTIME..

TIMESTATE(NOTIME) AND yWeek(5)- Notime

TIMESTATE(NOTIME) AND yDay(200)- Notime

When TIMESTATE(NOTIME) is ORed with other elements in a set, the values contained in all other elements will be returned as true.

TIMESTATE(NOTIME) OR yDay(200)- the 200th day of the year

TIMESTATE(NOTIME) OR mWeek(2)- the 2nd week of the year

TIMESTATE(ALLTIME) AND GREG(742) - the Gregorian year 742 CE holds for a certain predicate.

TIMESTATE(NOTIME) AND GREG(742) the Gregorian year 742 CE does not hold for a certain predicate.

4.4.5. For future consideration

All values in Orlando are represented as intervals of time. In cases where intervals are not known or not relevant the value terms UNTIL and SINCE can be used. Of course this might not always be suitable. We might know that Charlemagne was born in the year Greg(742) but we might not be sure of the exact date or time. Obviously Charlemagne's birth did not stretch out over the entire year. People don't fuss about this sort of thing but machines might. A homogeneous temporal state could be qualified by a non-homogeneous state. Here are some TIMESTATE examples expressing values that are not expressing binarity .

TIMESTATE(SOMETIME) AND GREG (742)

TIMESTATE(SCHEDULED) AND GREG (742)

TIMESTATE(TENTATIVE) AND GREG (742)

TIMESTATE(PROLEPTIC) AND GREG (742)

1.5. Variables

A Variable has the following format

 "VAR" "("  Nmtoken ")" 

Nmtoken  = as defined in XML1.0 

Datetime scheduling will invariably want to reuse previously declared sets. If one wanted to declare the opening times of several different voting booths as in the voting booth example below, it would be expedient to avoid having to repeat lengthy sets that one wished to intersect with.

For this purpose Orlando has an ID/Idref mechanism that lets us declare and use datetime set variables. We will use the operator DECLARE to create equivalence between the Variable and the associated set. See below.

1.5.1. External Referencing

It is likely that one would want to use declared variables to reference external representations through URI's. In the example above, the ElectionDay declaration could be found at one remote location and the Booth1 declaration at a third.

In an another example, if a boat was scheduled to leave the harbor at a time that was known to vary, then that time could be externally referenced through the boat company's web page, and an updated departure time could automatically be noted with each new refresh of the web page. Or - an SMS notifying agent could be automatically triggered by such changes. External referencing raise some serious info-logistic problems, which are out of scope for this paper - but be warned.

1.5.2. Base variables

We will not attempt to define specific Orlando base datetime variables here, but their usefulness is readily apparent.

Some possible candidates for base variables

• Government and religious holidays - particularly Movable Feasts

• Equinoxes

• Solstices -Aphelion and Perihelion

• Fractions of the lunar cycle - full moon

• Sun-ups and Sun-downs

• Tide movements

• Daylight saving schemes

• Times at geographic coordinates

If all schedulers knew that there was an online machine readable representation of say - Easter, such as www.gov.se/Sweden/Holidays/Easter, then providing they were aware of whose jurisdiction they were calculating for, they could intersect Easter into their schedules without having to resolve its yearly whereabouts. This would even be of greater utility for Ramadan, and other sorts of religious occasions whose precise dates are determined by astronomical sightings and religious decree.

Note that the user of base variables that receive their values through external referencing must be prepared for the possibility that at any given time the values of these variables can not be accessed.

1.6. Element Values

1.6.1. Text values

Though text values can be used in any element as indicated in the table below, the text values SINCE and UNTIL will usually be used in anchored elements such as Greg and the text values ALLTIME and NOTIME will normally be used in the TIMESTATEelement.

Table 6: Value Terms

Name	Used in
SINCE	value pairs
UNTIL	value pairs
ALLTIME	singular intervals
NOTIME	singular intervals

6.1.1. SINCE

The text value SINCE can be used as the trailing value in any element representing a datetime value pair. SINCE indicates that the interval initiated by the preceding value has no limits forward in time.

Note: The use of SINCE in reoccurring elements might have the effect of obliterating intended constraints. For example yWeek(34/SINCE) would begin a an infinite interval every 34th week of the year, so that one such interval left unconstrained would overlap all other intervals.

6.1.2. UNTIL

The text value UNTIL can be used as the trailing value in any element representing a datetime value pair. UNTIL indicates that the interval terminated by the preceding value has no limits backwards in time.

Note: The use of UNTIL in reoccurring elements might have the effect of obliterating intended constraints. For example yWeek(34/UNTIL) would terminate an infinite interval every 34th week of the year, so that one such interval left unconstrained would overlap all other intervals.

6.1.3. ALLTIME

The text value ALLTIME can be used as the sole value of any element representing a singular interval. ALLTIME indicates a state that holds for all eternity.

6.1.4. NOTIME

The text value NOTIME can be used as the sole value of any element representing a singular interval. ALLTIME indicates a state that does not hold for all eternity.

1.6.2. Compound Datetime Unit Values

A Compound datetime value has the following format

PrimaryElementValue  *[ p-DurationCode n ] 

p-DurationCode (Y | M | W | D ) [ T ( H | M | S ) ] 

It may be convenient to abut value types of greater precision to the datatype elements. All datetime unit elements can include datetime-unit values of a lesser valeur (greater precision) . To keep the examples here simple, we try to avoid such compound unit values, but if used correctly they make for compact sets that are easy to read. The following are all equivalent:

Greg(2005) AND yMonth(Jan) AND mDay(17) AND Hour(9) AND Minute(10)

Greg(2005-01-17T09:10)

GREG(2005) AND dYear(2005M01D17T09:10)

GREG(2005) AND yMonth(01D17T09:10)

GREG(2005M1) AND mDay(17T09:10)

GREG(2005M1D17) AND Hour(09:10)

GREG(2005-011-17T09) AND Min(10)

Note that the interval in both examples above is still only the tenth minute (the most precise valeur).

The rules for compound-unit values are:

6.2.1. Compound time unit values

A Compound time value has the following format

PrimaryElementValue  [  p-TimeDurationCode n ] 

p-TimeDurationCode ( H | M | S ) ] 

Time values preceded by a "T" character in ISO8601 extended format may be abutted to any Date value provided they are of complete representation ISO8601 5.3.1.1 or reduced precision ISO8601 5.3.1.2, but not truncated representation ISO8601 5.3.1.4

Hour(12:11:59) or Hour(12M11S59 - the last second of the 11th minute of the 12th hour of any day

Min(12:11) or Min(12S11)- the 11th second of the 12th minute of any hour of any day

Sec(12) - the 12th second of any minute of any hour of any day

Hour(12S12) - the 12th second of any hour of any day

Representation of decimal fractions are allowed and encouraged for value-pair intervals in Orlando, but fractions may not be used for singular representation, since fractions denote points and not intervals. The following example declaring the first three quarters of the 14th hour is good:

Hour(14/14.75)

But the following, being only a point in time and not an interval, is not good.

Hour(14.75)

Note: ISO8601 recognizes the use of a full stop "." for indicating fraction values, but the comma "," is strongly recommended in that document. Since we reserve the use of the comma for logically ORing multi-values in one datetime element, in Orlando we will only use the full-stop "." character to indicate the presence of fractional values.

6.2.2. Compound reoccurring datetime unit values

Date and time values of a lesser valeur can be abutted to an existing date value in accordance with ISO8601 5.4.1 using the ISO8601 extended format. ISO8601 truncated representation is not allowed, though complete and reduced precision representations are.

Months preceded by the Character "M", can be abutted to year values.

Weeks preceded by the character "W", can be abutted to month and quarter and year values.

Days preceded by character "D", can be abutted to years, quarters, months and weeks.

yDay(111T09)the ninth hour of the 111th day of any year

yWeek(11-03)the 3rd day of the 11th week of any year

yMonth(11-03)the 3rd day of the 11th month of any year

yMonth(11W2-05)the 5th day of the second week of the 11th month of any year

Quarter(3W2-05)the 5th day of the second week of the third quarter of any year

yMonth(11-03T15:15//11W2-05)from 3:15pm on the 3rd day of the 11th month to the 5th day of the second week of the 11th month of any year

6.2.3. Compound Gregorian datetime unit values

Date values of a lesser valeur can be abutted to an existing date value. ISO8601 Truncated representations are not allowed. If reduced precision representations are desired, the appropriate identifying characters as shown above; M, W and D must precede them. With complete representation of year, month and day, no identifying characters are needed.

Examples for Gregorian representation

Greg(11000-05-11T09:10:05Z)the fifth second of the 10th minute of the ninth hour of the 11th day of the 5th month of the year 11,000

Greg(52-03-09)the 9th day of the 3rd month of the year 52 (Not 1952!)

Greg(2025W19-05)the 5th day of the 19th week of the year 2025

Greg(2025D233)the 233rd day of the year 2025

In accordance with ISO8601 5.5.3.2 the values used in Gregorian Elements must not exceed the "carry-over" points of 12 months, 30 days, 24 hours, 60 minutes and 60 seconds. This of course does not apply to the duration values of Duration-explicit periods.

1.7. Cycles

Reoccurrence is the natural state of affairs in Orlando. Businesses are open, movies are shown, classes are held, tasks are performed recurrently. The greater part of these reoccurrences are what we call natural. With that we mean reoccurrences that can be described with one single instance of a datetime unit. Everyday, or every Monday, every week and so forth are all reoccurrences that, not only self describe their cycles, but synchronize with each other. These cycles are denoted in the table of date-time units above.

1.7.1. Defining alternate cycles

Up to now we have concentrated on datetime-unit symmetric reoccurrences. That is, reoccurrences that default into a cycle based on the natural cardinality of the set. On a macro level these will suffice for the greater part of human scheduling and they are of course mnemonic.

Minutes naturally loop in cycles of 60. Hours naturally loop in cycles of 24. Of course for some datetime units there exists more than one natural cycle. Numbered days for example, have natural ordinal cycles in weeks , months, and years.

Yet all scheduling is not datetime-unit symmetric. It is not uncommon for workers on shifts to utilize datetime-unit asymmetric scheduling schemes, such as 3 days on - 2 days off. Divorced parents often end up with horribly asymmetric schedules for sharing children. And as schedules address lesser spans of time - such as those exemplified in SMIL 2.0, datetime-unit symmetry tends to have less utility.

In order to express such alternate reoccurrences, the natural frequencies used by default must be replaced by alternate cycles. In the example of US presidential elections, a frequency of every-four-years is needed.

(Every 4 years) AND (mDay(2//9) AND wDay(Tu) AND yMonth(Nov))

Orlando uses the P-Durations of ISO8601 section 5.5.3.1 to show the range of non datetime unit symmetric cycles.

The existence of a P-duration following a datetime unit element name denotes that the natural cycle of the unit is being replaced by the P-duration. In the example below the Gregorian Date Greg(1) is used to indicate when the YearP4Y(4) cycle begins.

Greg(1/SINCE) AND YearP4Y(4) AND (mDay(2//9) AND wDay(Tu) AND yMonth(Nov)) - the fourth year of a four year cycle

1.7.2. Backwards occurrences of datetime unit values

A backwards occurrence of a datetime unit value has the following format

  "(" -  n ")"

RFC2445 allows the addition of numbers to named days in order to indicate their occurrence in the month or year. These are useful additions, since many events are scheduled to occur on the nth occurrence of a particular day in the month or year, i.e. the last Tuesday in March. Though such occurrences can often be worked out in Orlando using puzzle-logic, for example, the first Monday in a month can be indicated by; mDay(1//7) AND wDay(Mo) the puzzling gets trickier when we want to indicate the last Weekday, or Week-number, of the cardinally uneven month and year. With complicated sets we will loose a mnemonic overview. For this reason Orlando includes backwards ordering values for monthday, yearday, monthweek, and yearweek. In these elements, a preceding "-" sign will reverse the ordering of the subsequent value so that for example, " -1" indicates the last occurrence and "-3" the third from the last occurrence.

mDay(-4) - the fourth to the last day of any month

yDay(-3) - the third to the last day of any year

mWeek(-2) - the second to the last week of any month

yWeek(-1) - the last week of the year

Also in keeping with the syntax of RFC2445 Orlando uses both a minus and a plus sign to indicate the particular occurrence of a named weekday in a particular cycle. Normally named weekdays can only be used as values in the wDay element. If a named weekday value type is used in another element it will be to indicate the numbered occurrence of that particular named day.

A numbered occurrence of a named day has the following format

 ( [ + ] | [ ( - | + ) ] ) n DayName 

DayName ( Mo | Tu | We | Th | Fr | Sa | Su )  

mDay(-1Mo) - the last Monday of any monthly cycle

mDay(-2Mo) AND yMonth(Jan) - the second to last Monday in January

yDay(-3Mo) AND oYear(25) - the third to the last Monday every 25th year

mDay(+1Mo)- the first Monday of any monthly cycle

mDay(+2Mo) AND yMonth(Jan) - the second Monday in January

yDay(+3Mo) AND Year(25) - the first Monday every 25th year

mDay(-1) AND mDay(+3Mo) - only true if the last day of the month is the third Monday of the Month - an impossibility

Note: We are on the mnemonic edge here. yDay(1Tu), representing the first Tuesday in the year, appears quite similar to yDay(1T01), representing 1am on the first day of the year.

The RFC2445 iCal rule, BYSETPOS has caused a great deal of discussion.

The following example is cited in RFC2445; "the last work day of the month" and represented in RFC2445 notation as:

RRULE:FREQ=MONTHLY;BYDAY=MO,TU,WE,TH,FR;BYSETPOS=-1

In Orlando this could either be represented with a spatial operator:

mDay(-1Mo,-1Tu,-1We,-1Th,-1Fr) FINISHES day(1)

or using a mathematical operator:

mDay(-1Mo,-1Tu,-1We,-1Th,-1Fr) SETPOS(-1)

1.8. Intervals

In Orlando all values, even of the singular type, are to be considered intervals of time. Year(2010) is the interval of time between the first and last instance of the ordinal year 2010. yMonth(Dec) is the interval of time between the first and last instance of all months named December. Min(22:10) is the interval of time between the 9th and 11th second of the 22 minute. Intervals for singular element values are always determined by the most precise datetime unit value (the datetime unit furthest to the right, so Min(22) is the interval of time between the 21st and the 23rd minute of any hour.

Anchored datetimes in a singular value representation such as Greg(2111) are actually composed of three intervals. A) The interval between the epoch of the Gregorian calendar and the first instance of the singular value. B) The interval represented by the value itself. C) The interval between the last instance of the value and eternity.

1.8.1. Singular Intervals

A singular interval has the following format

 ElementName "(" SingularValue ")" 

SingularValue  = any valid combination of datetime unit values with out the presence of a solidus character   

Singular Intervals do not use the Solidus character to indicate a time period.

In the examples above we have mostly been showing elements with singular values such as yMonth(Jan) and Hour(5). Greg(2002) for example is an interval that begins after Greg(2001) and ends before the interval Greg(2003). wDay(Mo) is the interval that begins after wDay(Su) and ends before wDay(Tu). Hour(9)is the interval that begins after HOUR(8) and ends before HOUR(10).

1.8.2. Value Pair Intervals

A value-pair interval has the following format

 ElementName "(" SingularValue ( "/" | "//" ) SingularValue 

Value-pair intervals are the traditional representation of intervals in RFC2445. If we want to show an interval of months between January and October, or the hours between 9 and 17, for which no singular values suffice, we can do so in Orlando by using two singular values separated by one or two Solidus characters "/".

1.8.3. End inclusive - End exclusive Intervals

In the following examples using only one Solidus, an anomaly in human mnemonics becomes apparent.

yMonth(Jan/Oct)

Hour(9/17)

goal is to stay within a mnemonic framework for the representation of datetimes, but by keeping to convention we have touched upon an anomaly. Though we might be perfectly content to accept that yMonth(Jan-Oct) is the interval beginning after the end of yMonth(Dec) and ending at the beginning of yMonth(Nov), if someone tells us to work from nine till five, we expect to go home at five and not at six.

The problem is that in everyday life we use end-inclusive and end-exclusive representations intermittently in different contextual frameworks. To mandate the exclusive use of one or another would be heavy handed and counter-mnemonic, so here is a method that provides for both types.

End-inclusive intervals are indicated by two Solidus characters, "//" and end-exclusive are indicated by one "/". Hour(9/17) indicates that the interval ends at the beginning of Hour(17), and Hour(9//17) indicates that the interval ends at the beginning of HOUR(18). yMonth(Jan/Oct) indicates that the interval ends at the beginning of October, while yMonth(Jan//Oct) ends at the beginning of November.

Note: We are heavy-handedly decreeing that all values are start-inclusive since that is so extremely common. But inn an element such as Greg(1000T13:20:20/SINCE) it might be unclear whether we should begin our interval at the start or the end of the 20th second. The start-inclusive rule determines that we begin the interval at the start of the 20th second.

1.8.4. Duration/Period Explicit Intervals

Since leap seconds are periodically added to UTC we can not know for sure that any minute picked at random is exactly 60 seconds in duration, or that any random day is exactly 86,400 seconds long. We can not know that any random month will consist of 30 days or any year made up of only 365. But we have learned to deal with this and we willingly forego exactness in scheduling in favor of convenience.

In Jules Verne's Around the World in 80 days, a device is used to enliven the story. One might suspect that the story is actually the result of the device. For the bet to be won; was the global circumvention to take exactly 80 days as reckoned by Phileas and Passepartout on their voyage eastward around the world, or was it to take 80 days as reckoned by his friends, home in London?

Orlando can indicate whether exact durations or calendar date intervals are intended, by defining an interval type for each. These two types are called period-explicit and duration-explicit. Note: in RFC2445 these two types are called Period-explicit and Period-start but the Orlando Duration-explicit interval type has a significance here that is not covered by Period-start.

8.4.1. Period Explicit Intervals

A Period Explicit interval has the following format

 ElementName "(" SingularValue  ( "/" | "//"" ExpSingularValue ")" 

ExpSingularValue  = any valid combination of datetime unit values not preceded by a "P" character 

A Period-Explicit interval is one in which the clock and calendar at the geographical points of the interval's beginning and end delimit the interval. In a Period-explicit interval, the duration can only be derived through complete knowledge of all geopolitical coordinates, intercalation of leap year days, leap seconds, daylight saving schemes, the crossing of international datelines or any politically mandated time alterations that might effect the time on the wall clock and the date on the calendar.

Period-explicit examples

Greg(2000-01-01/2000-03-01)

Hour(8//7)

JD(2452177.23965/2452277.23965)

8.4.2. Duration Explicit Intervals

A Duration Explicit interval has the following format

 ElementName "(" SingularValue  ( "/" | "//"" ExpDurationValue ")" 

ExpDurationValue  = any valid combination of datetime unit values preceded by a "P" character 

In a Duration-Explicit interval, it is the clock and calendar at one of the geographical points of the interval's beginning or end, plus (or minus) the duration that delimits the interval. In a Duration-explicit interval, the datetime pointed to by the duration can only be derived through complete knowledge of all geopolitical coordinates, the intercalation of leap year days, leap seconds, daylight saving schemes, the crossing of international datelines or any politically mandated time alterations that might effect the time on the wall clock and the date on the calendar.

Note: The RFC2445 rules for Period-start (duration-explicit) differ from ISO8601. The difference has to do with how to indicate whether a duration of time begins at a particular calendar point or ends at it. ISO8601 indicates this by the ordering of the value-pair. If the duration precedes the anchoring datetime, it is to be subtracted from the datetime; if it follows it, it is to be added. RFC2445 only allows for the duration to follow the anchoring datetime and indicates with a minus or (optional) plus sign whether the duration is to be subtracted or added. In the Orlando model we will use the RFC2445 method, believing it will make life easier on parsers.

Duration-explicit examples

Hour(8//-P23h)

MJD(2452177/P100D)

Note : The MJD example is the equivalent of what is known as DOY (Day of the year) notation, frowned upon by some members of the scientific communityhttp://tycho.usno.navy.mil/.

Mapping between duration-explicit and period-explicit representation normally requires access to external knowledge and can not be resolved merely with the help of formulas. Civil clocks and calendars are subject to political jurisdiction, particularly in matters concerning daylight saving.

1.9. Operators

Table 7: Operators

Name	expression	type
AND	conjunction	logical
OR	disjunction	logical
DECLARE	equivalence	logical - declarative
STARTS	relevance	temporal
FINISHES	relevance	temporal
DURING	relevance	temporal
MEETS	relevance	temporal

1.9.1. Logical Operators

The operator AND denotes conjunctions of intersecting elements so that only those values which are common to all elements in the set are true. The operator OR denotes disjunctions (unions) of elements where that which is true in any element in the set is returned as true for the entire set.

9.1.1. AND

The AND operator joins sets in the following manner.

 precedingSet AND trailingSet 

precedingSet  = any valid set of elements preceding the AND operator 

trailingSet  = any valid set of elements trailing the AND operator 

AND is the fundamental operator in Orlando. AND causes the intersection of values for members of adjacent sets. AND is the logical model for natural language representation of dates and times. For example saying "2pm on June 3rd, 2025", is the equivalent of saying "of all hours of all days of all months of all years we designate the 14th hour AND the third day AND the 6th month AND 2025th year and no others.

More than 2 sets can be simultaneously intersected by the chaining of AND operators. ex.

(set₁) AND (set₂) AND (set₃) AND (set₄)

Is the equivalent of AND(set₁ set₂ set₃ set₄)

ANDs can be nested. Left-Right parentheses-counts determine subset membership.

(set₁) AND ((set₂) AND (set₃) AND (set₄))

Is the equivalent of AND(set₁ (AND(set₂ set₃ set₄))

9.1.2. OR

The OR operator joins together sets in the following manner

 precedingSet "OR" trailingSet

precedingSet  = any valid set of elements preceding the OR operator 

trailingSet  = any valid set of elements trailing the OR operator 

OR causes the UNION of values for members of adjacent sets. A union returns as true the intervals of all the elements in the union.

There are two methods for indicating unions. The following examples are equivalent and describe all Mondays and all Thursdays.

wDay(Mo) OR wDay(Th)

wDay(Mo,Th)

The rule here is that one can separate by commas any singular or paired-interval values within the same data-type element to indicate a union. But unions of different data-type elements must be indicated with an OR operator joining separate elements. The following example demonstrates both representations of a union and returns all Mondays in January, forever plus all Tuesdays and Wednesdays, forever.

(yMonth(Jan) AND wDay(Mo)) OR wDay(Tu,We)

More than 2 sets can be simultaneously joined in union by the chaining of OR operators. ex.

(set₁) OR (set₂) OR (set₃) OR (set₄)

Is the equivalent of OR(set₁ set₂ set₃ set₄)

ORs can be nested. Left-Right parentheses-counts determine subset membership.

(set₁) OR ((set₂) OR (set₃) OR (set₄))

Is the equivalent of AND(set₁ (OR(set₂ set₃ set₄))

Note: Nesting is the equivalent of sentential bracketing. OR unions return all explicit values. In the immediate example above, nesting (bracketing) has no effect on the outcome.

9.1.3. DECLARE

DECLARE assigns a value to a named variable. The variable takes on the value of the set it is DECLARED with.

 DECLARE Nmtoken Set

The set associated to the variable can contain any number of subsets.

In the example below we will first DECLARE the opening hours of a voting both and the date of the election and then logically AND them together in a new declaration.

DECLARE Booth1 (Hour(9:15/13))

DECLARE ElectionDay Greg(2004) AND mDay(2//9) AND wDay(Tu) AND yMonth(Nov)

DECLARE Booth1Open (VAR(Booth1) AND VAR(ElectionDay))

We can then use the variable Booth1Open in an application. Figuratively something like the following:

"Booth One is open for voting at VAR(Booth1Open) for your convenience."

. If you wanted to make a datetime declaration dependent on some unknown future circumstance you could include a place holder for the outcome of that circumstance.

Here is a trivial example: Normally there is a Swapmeet on either Saturday or Sunday at a particularly rainy geographic coordinate X/Y. The organizers state that if a >65% forecast for rain at X/Y is in force at 4am on the Saturday in question the Swap Meet will take their chances with Sunday instead. Potential swappers and the organizers are all asleep Saturday morning at 4am, but whenever they wake up, they will all know if the swap meet is that day or the next. We are not going to try to solve the problems of querying the metrological service and submitting the coordinates here, we will just say that this is carried out and that the results are made available as a true/false condition at a particular URL.

DECLARE NoRain TIMESTATE(ALLTIME )

(NoRain) AND wDay(Sa) AND Hour(10//15) - the Swapmeet will be on Saturday

DECLARE NoRain TIMESTATE(NOTIME )

VAR^(NoRain) AND wDay(Su) AND Hour(10//15 - the Swapmeet will be on Sunday

1.9.2. Temporal operators

In order to indicate temporal relationships between elements Orlando uses some of the interval relationships proposed by James Allen in 1983. "Maintaining knowledge about temporal intervals". We will include four Allen type relationships as operators. STARTS, FINISHES, DURING and MEETS.

9.2.1. STARTS

The STARTS operator is placed between sets in the following manner.

 precedingSet "STARTS" trailingSet

precedingSet  = any valid set of elements preceding the STARTS operator 

trailingSet  = any valid set of elements trailing the STARTS operator 

The STARTS operator aligns the beginning of two intervals. so in the example below a period of 6000 ordinal years begins simultaneously with the beginning of the Gregorian year 3000. The fact that the Gregorian element in the preceding set contains an interval of 1 year and one second has no bearing on the temporal positioning of the 6000 ordinal years of the trailing set. The returned value of a STARTS operator is the AND of the preceding and trailing sets so in the example below the 6000 years of the trailing set would be reduced to the year and a second matching the preceding set.

Greg(3000//3000T00:00:01) STARTS Years(6000)

In the following example, a one hour interval 9am is repeated on the first day of a 15 day period beginning simultaneously with the 2nd of September in the Year 2011 and ending on the last day of the year 2012

Greg(2011-09-02//2012) STARTS DayP15D(1T09)

9.2.2. FINISHES

The FINISHES operator is placed between sets in the following manner.

 precedingSet "FINISHES" trailingSet

precedingSet  = any valid set of elements preceding the FINISHES operator 

trailingSet  = any valid set of elements trailing the FINISHES operator 

The FINISHES operator aligns the ends of two intervals. In the example below a period of 6000 ordinal years ends simultaneously with the end of the Gregorian year 3000 plus one second. The fact that the Gregorian datetime element has an interval value of 1 year and one second has no bearing on the temporal positioning of the 6000 ordinal years. Note that neither STARTS or FINISHES are dependent on sentential order. Note also that any set containing just one instance of a temporal operator might also be represented by a duration-explicit interval.

Greg(3000//3000T00:00:01) FINISHES Year(6000)

Note that FINISHES implies an AND relationship between the members of its set.

In the following example, a one hour interval 9am is repeated on the first day of a 15 day period ending simultaneously with the end of the 2nd of September in the Gregorian year 2011. The beginning of the period must be calculated backwards in 15 day increments from the 2nd of September, 2011, but will not extend past the beginning of the first day of the Gregorian year 2005

Greg(2005//2011-09-02) FINISHES DayP15D(1T09)

9.2.3. DURING

The DURING operator is placed between sets in the following manner.

 precedingSet "DURING" trailingSet

precedingSet  = any valid set of elements preceding the DURING operator 

trailingSet  = any valid set of elements trailing the DURING operator 

The DURING operator relates two temporal sets so that the preceding set defines the start of an interval while the trailing set defines the end. This is equivalent to an interval as defined by a datetime value pair, but allows for the use of more complex logical statements.

The interval defined by DURING is both start and end inclusive. In the example below, an interval is returned extending from the start of the year 3000 until the end of the 1st Monday in June.

Greg(3000) DURING yMonth(Jun) AND wDay(1Mo)

Daylight saving time in Sweden begins on the last Sunday in March and ends on the last Sunday in October. In the example below we will DECLARE a variable for the interval of Swedish daylight saving. Later we will reuse that variable.

DECLARE SwedDST (yMonth(Mar) AND mDay(-1Su)) DURING (yMonth(Oct) AND mDay(-1Su))

In the year 2001 this would be the equivalent to Greg(2001-03-25/2001-10-28)

9.2.4. MEETS

The MEETS operator is placed between sets in the following manner.

 precedingSet "MEETS" trailingSet

precedingSet  = any valid set of elements preceding the MEETS operator 

trailingSet  = any valid set of elements trailing the MEETS operator 

The MEETS operator aligns two adjacent sets so that the end of the preceding set meets the start of the trailing set. In the example below, an interval of 3 hours inside a cycle of 39 hours, which repeats 8 times, is abutted to the end of every January forever.

yMonth(Jan) MEETS (HourP39H(1//3) AND OCCURS(8))

1.10. Exceptions through negation

Negations can be used conveniently to represent exceptions. For example Holidays or lunch breaks can be exempted from valid dates and times with the help of negated values. Orlando lets us negate singular intervals or value-pair intervals. Keep in mind that in the later case it is the value pair and not the individual values that constitute what will be negated. The following example returns "all the days of December except for the 24th and 25th".

(mDay^(24//25) AND yMonth(12))

The following examples demonstrate various outcomes using negations:

Hour(9/17) AND wDay(Mo) - all Mondays between 9 and 17

Hour^(9/17) AND wDay(Mo) - All Mondays except between 9 and 17

Hour(9/17) AND wDay^(Mo) - All days except Mondays between 9 and 17

Hour^(9/17) AND wDay^(Mo) - All days except Mondays all hours except between 9 and 17

Hour(9/17) OR wDay(Mo) - everyday between 9 and 17 and all day (24hours) Monday

Hour^(9/17) OR wDay(Mo) - everyday for all hours not between 9 and 17, yet all day on Monday