| |
Table of contents | Author | City | Company | Country | State/Province | Term | Interchange | |
FitzPatrick, Greg , Chief Scientist , SkiCal Consortium, Stockholm Sweden
Email: greg@skical.org
Greg FitzPatrick - a computer veteran of 25 years, does research in the evolvement of end-to-end markets and super directories. He is an adviser to the Swedish government's Information Technology Commission, a contributing author to the Swedish Governmental Enquiry on Infrastructure, an adviser to the National Education Agency and the Swedish National Tourist Council. He is the initiator and co-author of the SkiCal directory mark-up language. He is currently working with the Swedish National Labour Market Board in the development of an end-to-end labor market.
The first part of this presentation defines a model for the representation of datetime reoccurrences, calendars and queries. The second half will be a demonstration of RDF C&S models.
Part 1) The paper below presents a logical model,Orlando , for the representation of dates and times in a mnemonic yet machine readable format. It is intended that further XML-RDF C&S work can build upon the foundation of the Orlando model.
Part 2 ) The W3C RDF interest group taskforce on calendaring has been developing an RDF schema based on iCalendar RFC2445. Once information is converted to this format, RDF Query languages can be used to ask intuitive questions about events data by taking slices through events along the axes of WHEN, WHERE and WHO. The inspiration for this is the SkiCal conceptual framework for describing events - the 'WHAs'. For example - find me: the event last Thursday in the ILRT meeting room (WHERE) at 3pm local time (WHEN) the events that the person whose email address is danbri@w3c.org (WHO) was at which occurred last year sometime (WHEN) This presentation will illustrate practical applications of this technique using the Squish RDF query language.
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.
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.
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:
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.
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:
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.
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, t1 Average-Congestion t2 Minimal-Congestion t3 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 .
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.
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) 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:
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
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:
The Venn diagram illustrates the above example.
Intersection of 3 datetime elements
|
The following table shows the most common datetime units and their natural cycles.
The following table shows the less common datetime unit elements and their natural cycles.
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:
So from this year and indefinitely onward XML reigns supreme.
Before there was XML there were meetings of the Hodgepodge Club on Mondays
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//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 ...
...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.
| Datetime unit | Name | Natural cycle |
| Gregorian | Greg | none |
| Julian Date | JD | none |
| Modified Julian Date | MJD | none |
| Network Time Protocol | NTP | none |
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.
Adding more years will not help.
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.
| 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.
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-DurationsP-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
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.
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...
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
==> (1997 9:00 AM EDT)September 4;October 7 (1997 9:00 AM EST)November 6
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.
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//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:
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
When TIMESTATE(NOTIME) is logically ANDed with other elements in a set, the set value will be 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(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.
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 .
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.
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.
We will not attempt to define specific Orlando base datetime variables here, but their usefulness is readily apparent.
Government and religious holidays - particularly Movable Feasts
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.
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 TIMESTATE element.
| Name | Used in |
| SINCE | value pairs |
| UNTIL | value pairs |
| ALLTIME | singular intervals |
| NOTIME | singular intervals |
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.
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.
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)
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:
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
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:
But the following, being only a point in time and not an interval, is not good.
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.
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.
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
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
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.
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.
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-DurationsP-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
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.
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(-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(-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:
In Orlando this could either be represented with a spatial operator:
or using a mathematical operator:
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.
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).
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 "/".
In the following examples using only one Solidus, an anomaly in human mnemonics becomes apparent.
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.
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.
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.
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.
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 community .
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.
| 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 |
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.
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.
Is the equivalent of AND(set1 set2 set3 set4)
ANDs can be nested. Left-Right parentheses-counts determine subset membership.
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.
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.
More than 2 sets can be simultaneously joined in union by the chaining of OR operators. ex.
Is the equivalent of OR(set1 set2 set3 set4)
ORs can be nested. Left-Right parentheses-counts determine subset membership.
Is the equivalent of AND(set1 (OR(set2 set3 set4))
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.
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 ElectionDay Greg(2004) AND mDay(2//9) AND wDay(Tu) AND yMonth(Nov)
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.
(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
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.
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.
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
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.
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
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.
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)
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.
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".
The following examples demonstrate various outcomes using negations:
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
Hour(9/17) OR wDay^(Mo) - everyday all day except Monday between 9 and 17
Hour^(9/17) OR wDay^(Mo) - everyday all day except Monday all hours not between 9 and 17
Most of the datetime units repeat themselves in natural cycles inside larger datetime units. For example the hour repeats its count at the end of every day. Sometimes an interval crosses the boundary of two adjacent larger units as in "from 10pm to 3am the following day". This is called a midnight crossing . We don't want to loose the ability to describe the full cycle of datetime units on account of midnight crossings. We want to be able to make mnemonic statements like Hour(23/5) and mDay(25/23) or even dYear(5/3). The rule here is that if the value on the right hand side of the Solidus character(s) is smaller than the value on the left hand side, then the full cardinal number of the datetime unit will be added to the right hand side in order to calculate the duration implied by the pair. The following returns Friday, from 11:30 pm to Saturday at 3am, Saturday from 11:30pm to Sunday at 3am, and Sunday from 11:30pm until midnight.
A datetime unit that is signified to have an alternate cycle may not contain a midnight crossing value. The following is not correct
Note: ISO8601 5.5.4.1 does not stipulate whether any value to the left or right of the solidus should be lesser or greater than its value-pair companion
The examples used through out this paper contain sets of infinitely looping intervals. To unfold such a declaration would break the memory of any computer.
Today's calendar applications like to unfold reoccurrences and place them in their appropriate places on a calendar. Obviously alternate system approaches must be taken when dealing with infinite loops.
The way we have been intersecting sets in the examples in this paper is of course quite similar to how one would querying them. Effective storage and access to these sets could be accomplished in a rules-orientated environment. In such an environment. Gregorian, Julian Date and NTP timekeeping systems themselves could exist merely as a set of rules. An application could logically AND the truth of the calendar system, the truth of any schedule and the truth of a query all represented in Orlando logical statements.
Barbs Bakery is open Monday to Friday, 9 to 5 and Saturday 9 to 1, and closed Sundays. Barb takes a vacation in July
(Hour(9-5) AND wDay(Mo-Fr)) OR (Hour(9-1) AND wDay(Sa)) OR yMonth^(Jul)
Eddies working shift is 7 hours of work followed by 11 hours of free time. He does this for three days followed by two days of rest and then repeats the cycle again.
The street parking schedule for residents on Odengatan 98 in Stockholm
Greg(1990/SINCE) Hour(24/06) OR wDay^(Th) AND VAR(SwedishOfficialHolidays)- parking everyday all day except Thursdays between midnight and 06, if there is no official holiday falling on a Thursday.
The telephone times of a busy dentist
(Greg(2004/SINCE) Hour(8:15/8:30)) AND wDay(Mo,We,Fr) OR (Hour(13/13:15) AND wDay(Tu,Th)) OR VAR^(SwedishOfficialHolidays)- everyday all day except Thursday between 24 and 06
The following examples are from RFC2445. All examples assume the Eastern United States time zone. Each example is ordered as; the desired outcome of the declaration. The RFC2445 format. The Orlando format. The outcome
Note: These examples are not so much real life use-cases as they are vehicles for demonstrating the iCal reoccurrence capabilities. Unfortunately all the examples begin at nine AM and we never find out when they end.
DTSTART;TZID=US-Eastern:19970902T090000 RRULE:FREQ=DAILY;COUNT=10
==> (1997 9:00 AM EDT)September 2-11
Daily until December 24, 1997:
DTSTART;TZID=US-Eastern:19970902T090000 RRULE:FREQ=DAILY;UNTIL=19971224T000000Z
==> (1997 9:00 AM EDT)September 2-30;October 1-25 (1997 9:00 AM EST)October 26-31;November 1-30;December 1-23
DTSTART;TZID=US-Eastern:19970902T090000 RRULE:FREQ=DAILY;INTERVAL=2
==>(1997 9:00 AM EDT)September2,4,6,8...24,26,28,30; October 2,4,6...20,22,24 (1997 9:00 AM EST)October 26,28,30;November 1,3,5,7...25,27,29; Dec 1,3,...
DTSTART;TZID=US-Eastern:19970902T090000 RRULE:FREQ=DAILY;INTERVAL=10;COUNT=5
==> (1997 9:00 AM EDT)September 2,12,22;October 2,12
Everyday in January, for 3 years:
DTSTART;TZID=US-Eastern:19980101T090000 RRULE:FREQ=YEARLY;UNTIL=20000131T090000Z; BYMONTH=1;BYDAY=SU,MO,TU,WE,TH,FR,SA or RRULE:FREQ=DAILY;UNTIL=20000131T090000Z;BYMONTH=1
==>(1998 9:00 AM EDT)January 1-31 (1999 9:00 AM EDT)January 1-31 (2000 9:00 AM EDT)January 1-31
DTSTART;TZID=US-Eastern:19970902T090000 RRULE:FREQ=WEEKLY; COUNT=10
==> (1997 9:00 AM EDT)September 2,9,16,23,30;October 7,14,21 (1997 9:00 AM EST)October 28;November 4
Weekly on Tuesday and Thursday for 5 weeks:
DTSTART;TZID=US-Eastern:19970902T090000 RRULE:FREQ=WEEKLY;UNTIL=19971007T000000Z;WKST=SU;BYDAY=TU,TH
RRULE:FREQ=WEEKLY;COUNT=10;WKST=SU;BYDAY=TU,TH
Greg(1997-09-02//UNTIL) AND wDay(Tu,Th) AND (Hour(9) OCCURS(10)
==> (1997 9:00 AM EDT)September 2,4,9,11,16,18,23,25,30;October 2
Every other week on Monday, Wednesday and Friday until December 24, 1997, but starting on Tuesday, September 2, 1997:
DTSTART;TZID=US-Eastern:19970902T090000 RRULE:FREQ=WEEKLY;INTERVAL=2;UNTIL=19971224T000000Z;WKST=SU; BYDAY=MO,WE,FR
(Greg(1997-09-03//1997-12-24) AND wDayP2W(Mo,We,Fr) AND Hour(9))
==> (1997 9:00 AM EDT)September 2,3,5,15,17,19,29;October 1,3,13,15,17 (1997 9:00 AM EST)October 27,29,31;November 10,12,14,24,26,28; December 8,10,12,22
Monthly on the 1st Friday for ten occurrences:
DTSTART;TZID=US-Eastern:19970905T090000 RRULE:FREQ=MONTHLY;COUNT=10;BYDAY=1FR
Greg(1997-09-05//UNTIL) AND (mDay(1Fr) AND Hour(9)OCCURS (8)
==> (1997 9:00 AM EDT)September 5;October 3 (1997 9:00 AM EST)November 7;Dec 5 (1998 9:00 AM EST)January 2;February 6;March 6;April 3 (1998 9:00 AM EDT)May 1;June 5
Monthly on the second to last Monday of the month for 6 months:
DTSTART;TZID=US-Eastern:19970922T090000 RRULE:FREQ=MONTHLY;COUNT=6;BYDAY=-2MO
==> (1997 9:00 AM EDT)September 22;October 20 (1997 9:00 AM EST)November 17;December 22 (1998 9:00 AM EST)January 19;February 16
Monthly on the third to the last day of the month, forever:
DTSTART;TZID=US-Eastern:19970928T090000 RRULE:FREQ=MONTHLY;BYMONTHDAY=-3
==> (1997 9:00 AM EDT)September 28 (1997 9:00 AM EST)October 29;November 28;December 29 (1998 9:00 AM EST)January 29;February 26 ...
Every 3rd year on the 1st, 100th and 200th day for 10 occurrences:
DTSTART;TZID=US-Eastern:19970101T090000 RRULE:FREQ=YEARLY;INTERVAL=3;COUNT=10;BYYEARDAY=1,100,200
==> (1997 9:00 AM EST)January 1 (1997 9:00 AM EDT)April 10;July 19 (2000 9:00 AM EST)January 1 (2000 9:00 AM EDT)April 9;July 18 (2003 9:00 AM EST)January 1 (2003 9:00 AM EDT)April 10;July 19 (2006 9:00 AM EST)January 1
Monday of week number 20 (where the default start of the week is Monday), forever:
DTSTART;TZID=US-Eastern:19970512T090000 RRULE:FREQ=YEARLY;BYWEEKNO=20;BYDAY=MO
==> (1997 9:00 AM EDT)May 12 (1998 9:00 AM EDT)May 11 (1999 9:00 AM EDT)May 17 ...
Every Thursday in March, forever:
DTSTART;TZID=US-Eastern:19970313T090000 RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=TH
==> (1997 9:00 AM EST)March 13,20,27 (1998 9:00 AM EST)March 5,12,19,26 (1999 9:00 AM EST)March 4,11,18,25 ...
Every Thursday, but only during June, July, and August, forever:
DTSTART;TZID=US-Eastern:19970605T090000 RRULE:FREQ=YEARLY;BYDAY=TH;BYMONTH=6,7,8
==> (1997 9:00 AM EDT)June 5,12,19,26;July 3,10,17,24,31; August 7,14,21,28 (1998 9:00 AM EDT)June 4,11,18,25;July 2,9,16,23,30; August 6,13,20,27 (1999 9:00 AM EDT)June 3,10,17,24;July 1,8,15,22,29; August 5,12,19,26
Every Friday the 13th, forever:
DTSTART;TZID=US-Eastern:19970902T090000 EXDATE;TZID=US-Eastern:19970902T090000 RRULE:FREQ=MONTHLY;BYDAY=FR;BYMONTHDAY=13
Greg(1997-09-02//UNTIL) AND wDay(Fr) AND mDay(13) AND Hour(9)
==> (1998 9:00 AM EST)February 13;March 13;November 13 (1999 9:00 AM EDT)August 13 (2000 9:00 AM EDT)October 13 ...
The first Saturday that follows the first Sunday of the month, forever:
DTSTART;TZID=US-Eastern:19970913T090000 RRULE:FREQ=MONTHLY;BYDAY=SA;BYMONTHDAY=7,8,9,10,11,12,13
Greg(1997-09-13//UNTIL) AND (mDay(1Su)AND OFFSET(P6D) AND Hour(9)
==> (1997 9:00 AM EDT)September 13;October 11 (1997 9:00 AM EST)November 8;December 13 (1998 9:00 AM EST)January 10;February 7;March 7 (1998 9:00 AM EDT)April 11;May 9;June 13... ...
Every four years, the first Tuesday after a Monday in November, forever (U.S. Presidential Election day):
DTSTART;TZID=US-Eastern:19961105T090000 RRULE:FREQ=YEARLY;INTERVAL=4;BYMONTH=11;BYDAY=TU;BYMONTHDAY=2,3,4, 5,6,7,8
Greg(2000) STARTS YearP4y(1) AND mDay(2/9) AND wDay(Tu) AND yMonth(Nov)
==> (1996 9:00 AM EST)November 5 (2000 9:00 AM EST)November 7 (2004 9:00 AM EST)November 2 ...
Every 3 hours from 9:00 AM to 5:00 PM on a specific day:
DTSTART;TZID=US-Eastern:19970902T090000 RRULE:FREQ=HOURLY;INTERVAL=3;UNTIL=19970902T170000Z
We have avoided using UTC time zones in most of the examples in this paper, since they would not have affected the logical aspects of Orlando. But of course UTC coordinates may be used as shown in the examples below.
The last example is tricky. It says that an interval begins at 2pm according to one time zone at the Greenwich meridian, and ends at 8am according to a timezone 5 meridians to the west. This representation, or variations upon it are often used on airline tickets. In cases where the time change exceeds the duration one might be wise to include dates. Temporal statements, by the way should never imply spatial statements, though that is often done in desktop calendar programs.
UTC offsets may not be added to the duration values of duration-explicit intervals. The following examples are incorrect
It should be pointed out that while ISO8601 recommends the use of a minus "[-]" to indicate minus UTC Offset and the use of a hyphen [-] to separate value types for the ISO8601 extended format (also used in XML Schemas), these two graphical characters are notorious sources for confusion. One solution to this problem would be that all UTC offsets be indicated with a "Z" followed by an optional plus or minus character. This uses Z to denote both zero and non-zero UTC offsets. As exemplified below:
Graham Klyne and Chris Newman in their "Date and Time on the Internet: Timestamps" draft-ietf-impp-datetime-04.txt, write as follows
4.3. Unknown Local Offset Convention
If the time in UTC is known, but the offset to local time is unknown, this can be represented with an offset of "-00:00". This differs semantically from an offset of "Z" or "+00:00", which imply that UTC is the preferred reference point for the specified time. RFC2822 [IMAIL-UPDATE] describes a similar convention for email.
A mandatory Z would not effect the ability to indicate "-00:00" or "+00:00". .
Note: Keep in mind that the values we work with are convex intervals so that any timezone qualifier abutted to a compound datetime value applies to all the units in the value and not just, for example, the hour.
ISO8601 P-DurationsP-durations include the year and the month as possible values. Though this is quite suitable when defining cycles expected to land on reoccurring Calendar dates, it is not a good idea when defining accurate lengths of time for Duration-explicit intervals. There are two possible remedies. One, as adopted by RFC2445, is to leave out Months and Years as possible values in a P-duration. Two, is to give the Year and the Month precise definitions. This paper opts for the second alternative. Just keep in mind that a truncated Duration-explicit interval of one year can differ significantly from a truncated period-explicit interval.
The length of the Year for use in P-DurationsP-durations is equal to 365.242199 days, the length of a tropical year or 31,556,925.9936 sec.
The length of the Month for use in P-DurationsP-durations is equal to one twelfth of the tropical year.
"The uniform numbering of weeks necessitates a unique designation of the day on which a week begins. For commercial purposes, i.e. accounting, planning and similar purposes for which a week number might be used, Monday has been found the most appropriate as the first day of the week."
From this ISO8601 determines that "the first calendar week of a year is the one that includes the first Thursday of that year and that the last calendar week of a calendar year is the week immediately preceding the first calendar week of the next calendar year.
ISO8601 - NOTE 4 states: "The rule for determining the first calendar week is equivalent with the rule "the first calendar week is the week which includes January 4".
Of course many people consider the week to start on a Sunday. It is defined so in Webster's dictionary and on a lot of calendars. Computer operating systems such as the Macintosh OS, define Sunday as the first day of the week. For whomever the week starts on a Sunday the equivalence between the two ISO rules of "first Thursday" and "4th year day" does not hold. Some Calendar applications like that used in Palm Pilots allows for the setting of the first day of the week to either Sunday or Monday, but still use the Thursday rule.
In some countries, weeks are used quite expansively to schedule, but the inconsistencies in their ordering perhaps inhibits widespread cross-border use. Since we have included the element mWeek in Orlando, we must define it. The 4th day rule seems the best alternative.
The first week of the month is that week which intersects with the forth day in the calendar month.
We can define this using Orlando. First for Weeks that start on Monday and then for weeks that start on Sunday
It is not our intention to define all epoch-anchored timekeeping systems for the Orlando model. In Orlando examples we use only Gregorian, which represents a civil calendar, MJD which represents a scientifically useful day count and NTP, which represents a scientifically useful count of seconds. We will list some other systems here for reference.
The NTP uses the Time Protocol of RFC868 in which, time is the number of seconds since 00:00 (midnight) 1 January 1900GMT, such that the time NTP(1) is 12:00:01 am on 1 January 1900 GMT. The Network Time Protocol uses a 64-bit representation while the RFC868 protocol originally stipulated a 32-bit.
For example: the time NTP(2,208,988,800) corresponds to 00:00 1 Jan 1970 UTC, the time NTP(2,629,584,000) corresponds to 00:00 1 May 1983 UTC, and the time (-1,297,728,000) corresponds to 00:00 17 Nov 1858 UTC. The following represents all the Mondays in the period between 1970 and 1983
In the words of David Mills writing in the appendix to RFC1305
The UTC timescale thus ticks in standard (atomic) seconds and was set to the value 0h MJD 41,317.0 at the epoch determined by astronomical observation to be 0h on 1 January 1972 according to the Gregorian calendar; that is, the inaugural tick of the UTC Era. In fact, the inaugural tick which synchronized the cosmic oscillators, Julian clock, UTC clock and Gregorian calendar forevermore was displaced about ten seconds from the civil clock then in use, while the GPS clock is ahead of the UTC clock by six seconds in late 1990. Subsequently, the UTC clock has marched backward relative to the Julian timescale exactly one second on scheduled occasions at monumental epochs embedded in the institutional memory of our civilization. Note in passing that leap- second adjustments affect the number of seconds per day and thus the number of seconds per year. Apparently, should we choose to worry about it, the UTC clock, Julian clock and various cosmic clocks will inexorably drift apart with time until rationalized by some future papal bull.
The NTP timescale is based on the UTC timescale, but not necessarily always coincident with it. At 0h on 1 January 1972 (MJD 41,317.0), the first tick of the UTC Era, the NTP clock was set to 2,272,060,800, representing the number of standard seconds since 0h on 1 January 1900 (MJD 15,020.0). The insertion of leap seconds in UTC and subsequently into NTP does not affect the UTC or NTP oscillator, only the conversion to conventional civil UTC time. However, since the only institutional memory available to NTP are the UTC timecode broadcast services, the NTP timescale is in effect reset to UTC as each timecode is received. Thus, when a leap second is inserted in UTC and subsequently in NTP, knowledge of all previous leap seconds is lost.
The Julian date system is that invented by Joseph Justus Scaliger, Greg(1540//1609). It is the number of standard days since Julian proleptic(-4712) (January 1, 4713BC at T12:00). The Julian day begins at noon UTC. The day is divided by fractions. 0.5 of a Julian Day is equal to 12 Hour. One hour is equal to 0.041666667th of a day. The following examples are equivalent:
MJD is used to shorten the length of the Julian Date and move the start of a day to 00:00 as opposed to 12 noon. MJD is the Julian date minus 2400000.5
The following examples are equivalent:
Unix time uses the Gregorian datetime of 1970-01-01T00:00 UTC as it's anchoring epoch. Unix time is counted in whole seconds from that date.
The Julian calendar based on the 365.25-day year was replaced piecemeal by the Gregorian calendar beginning in 1582. Since the Julian calendar uses a smaller day base than the Gregorian calendar, the two systems do not remain in a constant relation of time to each other. The following are (were) equivalent.
The Windows epoch begins on the First of January 1900 and each standard day thereafter is given a count of 1. The time of day is stored and calculated in fractions of a standard day. This method is similar to that of the Julian Date.
Win(2958465.5/P1H) - an interval from 12 noon to 13:00 on the 31 December in the year 9999
The Macintosh epoch begins on the First of January 1904 and each standard day thereafter is given a count of 1. The time of day is stored and calculated in fractions of a standard day. This method is similar to that of the Julian Date.
Mac(2957003.5/P1H) - an interval from 12 noon to 13:00 on the 31 December in the year 9999
ISO8601:2000(E)5.5.3.1 Format with time-unit designators
In expressions of time-interval or recurring time-interval duration can be represented by a data element using time unit designators. The number of years shall be followed by the designator [Y], the number of months by [M], the number of weeks by [W], and the number of days by [D]. The part including time components shall be preceded by the designator [ T]; the number of hours shall be followed by [H], the number of minutes by [M] and the number of seconds by [S]. In the examples [n] represents one or more digits, constituting a positive integer or zero.
In basic and extended format the complete representation for duration shall be nYnMnDTnHnMnS or nW.
For reduced precision, decimal or truncated representations of this format the following rules apply.
a) If necessary for a particular application the lowest order components may be omitted to represent duration with reduced precision.
b) If necessary for a particular application the lowest order component may have a decimal fraction. The decimal fraction shall be divided from the integer part by the decimal sign specified in ISO 31-0: i.e. the comma [,] or full stop [.]. Of these, the comma is the preferred sign. The decimal fraction shall at least have one digit. If the magnitude of the number is less than unity, the decimal sign shall be preceded by a zero (see ISO 31-0).
c) If the number of years, months, days, hours, minutes or seconds in any of these expressions equals zero, the number and the corresponding designator may be absent; however, at least one number and its designator shall be present. Note that the removal of leading non-zero components is not allowed.
d) The designator T shall be absent if all of the time components are absent.
The major source of information on calendaring and scheduling used in preparing this paper comes from the work in process of the CALSCH WG
in the IETF Applications Area. The mailing list is accessible
, but the most expedient access to the iCalendar knowledge base is via a search application
maintained by one of our members, Bruce Kahn of IRIS Systems. RFC2445 
is available at the IETF archives or at the iCal..Org home page.
Please note that RFC2445 is only one member of a family of documents describing iCal . For historical reference to vCal, the predecessor of iCal, developed by the Versit Consortium, the original white paper is available at the Internet Mail Consortium
The SkiCal extensions to iCal can be found at
. The author's original paper on SkiCal is located here.
The mailing list of the RDF calendaring group can be found here
. A simple RSS Event model in RDF by Soren Roug
A Dublin Core Period Encoding Scheme by Simon Cox can be found here
A note by the author describing iCal for the newly formed RDF calendaring mailing list
The reefknot project's Perl toolkit for iCalendar/RFC2445 compliant calendaring is here.
ISO8601 is a publication financed standard and not freely available for distribution on the Internet but at the time of this writing it was available here . XML Schemas Part 2 Datatypes can be downloaded from the W3C Smil2.0 Timing and Synchronization Module can be downloaded from at the W3C Other sources of information on datetime formats can be found at the US Naval Observatory , NIST, and the NPL. An interesting article on time synchronization is in the appendix of RFC1305 This is the NTP RFC1305 author David Mill's homepage where other papers can be found.
Calendopaedia has lots of interesting calendar information, but one would be advised to cross-reference with other sources.
National Institute of Standards and Technology (NIST) has a tutorial for laymen entitled "The Evolution of Time Measurement"
The Official Source of Time for the Department of Defense and the Standard of Time for the United States
There is a considerable amount of literature in the AI community on the subject of temporal logic and temporal granularity. James Allen's 1983 paper is cited in almost any reading. That paper is not freely distributed on the Internet but some other Allen
& et al papers are. . Peter Ladkin's homepage is here:
Other AI work referenced in the preparation of this paper; .
It is interesting to note that in all of AI papers researched, there are absolutely no references to the tools, experiences and methods of the existing C&S community. Of course much of the AI precedes the CALSCH effort.
Metamatrix Development and Consulting AB, who have financed the major part of the research invested in this paper. The CALSCH WG under the chairmanship of Pat Egan and Bob Mahoney and Area Director Patrik Fältström, whose members have contributed extensively to the ideas presented here. The SkiCal Consortium WG, Pär Lannerö, Niklas Hjelm, Ingemar Eriksson, Johan Hjelm. Libby Miller, Dan Brickley and the RDF Calendaring Task Force.
[ICAL] F. Dawson, D. Stenerson "Internet Calendaring and Scheduling Core Object Specification" (iCalendar) Network Working Group RFC: 2445 November 1998 http://www.faqs.org/rfcs/rfc2445.html
[IMIP] [] Dawson, F., Mansour, S. and S. Silverberg, "iCalendar Message-based Interoperability Protocol (IMIP)", RFC 2447, November 1998.
[ITIP] Silverberg, S., Mansour, S., Dawson, F. and R. Hopson, "iCalendar Transport-Independent Interoperability Protocol (iTIP) : Scheduling Events, Busy Time, To-dos and Journal Entries", RFC 2446, November 1998.
[IMP] Bob Mahoney, Alexander Taler, George Babics "Implementers' Guide to Internet Calendaring" http://www.ietf.org/proceedings/00jul/I-D/calsch-imp-guide-01.txt
[CAP] S. Mansour, D. Royer, G. Babics, P. Hill, "Calendar Access Protocol" (CAP) draft-ietf-calsch-cap-05 http://www.ietf.org/internet-drafts/draft-ietf-calsch-cap-05.txt
[VCAL] [] Internet Mail Consortium, "vCalendar - The Electronic Calendaring and Scheduling Exchange Format", http://www.imc.org/pdi/vcal-10.txt, September 18, 1996.
[GFP01] G FitzPatrick "Understanding iCal ;amp; Mime-Directories" http://lists.w3.org/Archives/Public/www-rdf-calendar/2001May/0043.html
[JFP] F. Pollastri - "The Time of Internet" http://toi.iriti.cnr.it/uk/ntp.html
[NPL] "SI conventions" http://www.npl.co.uk/npl/reference/si_conventions.html National Physical Laboratory, UK
[ALL83] J. F. Allen. Maintaining knowledge about temporal intervals. Communications of the ACM, 26(11):832-843, 1983.
[ALL84] J. F. Allen. Towards a general theory of action and time. Artificial Intelligence, 23:123-154, 1984.
[IJC85] J.F. Allen and P.J. Hayes A common-sense theory of time. In Proc. of the Ninth IJCAI-85, pages 528-531, Los Ange-les, CA, 1985.
[BWJ98] C. Bettini, X. S. Wang, and S. Jajodia. A general frame-work for time granularity and its application to temporal reasoning. Annals of Mathematics and Artificial Intelligence, 22(1,2):29-58, 1998.
[ISO8601] ISO/TC 154 ISO8601:2000(E) Data elements and interchange formats - Information interchange - Representation of dates and times Second edition 2000-12-15
[ALL91] Allen, J.F. "Time and time again: The many ways to represent time," Int'l. Jr. of Intelligent Systems 6, 4, 341-356, July 1991
[AF94] Allen, J.F. and Ferguson, G. Actions and Events in Interval Temporal Logic, J. Logic and Computation 4, 5, 1994.
[JFA91] Allen, J.F. Planning as Temporal Reasoning. In Proc., 2nd Principles of Knowledge Representation and Reasoning, Morgan Kaufmann, 1991.
[CD00] Diana Cukierman and James Delgrande A Formalization of Structured Temporal Objects and Repetition, Proceedings of the Seventh International Workshop on Temporal Representation and Reasoning (TIME'00)
[JW] Jesse Weissman A Brief History of Clocks: From Thales to Ptolemy, http://www.perseus.tufts.edu/GreekScience/Students/Jesse/CLOCK1A.html
[ETOO] Ed Trump, Time, Standard Time and Western Union, http://www.metronet.com/~nmcewen/time.html
[KK00] Making Time on Planet Earth by Ken Kalb http://www.lightshift.com/Inspiration/chapter7.html LightShift 2000 initiative! ISBN: 0-9642927-7-7
[MK] Markus Kuhn A Summary of the International Standard Date and Time Notation http://www.cl.cam.ac.uk/~mgk25/iso-time.html
[NTP] Mills, D., "Network Time Protocol (Version 3) Specification, Implementation and Analysis", RFC 1305, University of Delaware, March 1992.
[KN00] G. Klyne, Baltimore Technologies Internet Draft C. Newman, Sun Microsystems Date and Time on the Internet: Timestamps Network Working Group Internet Draft
[MSK96] Morris, R., Shoaff, W. D., and Khatib, L., Domain-Independent Temporal Reasoning with Recurring Events, Computational Intelligence Journal, Volume 12, Number 3, August 1996
[LL78] Leslie Lamport, Time, clocks, and the ordering of events in a distributed system. Communications of the ACM, Vol. 27, No. 7, July 1978, pp. 558-565
[PSJ] Yingjiu Li Peng Ning X. Sean Wang Sushil Jajodia, Discovering Calendar-based Temporal Association Rules, Center for Secure Information Systems George Mason University, Fairfax, VA
[BL97] Simple Reasoning With Time-Dependent Propositions [ Abstract | Postscript | DVI ] Maroua Bouzid and Peter Ladkin To appear in the Journal of the IGPL, 1997.
| |
Table of contents | Author | City | Company | Country | State/Province | Term | Interchange |