There are two major ways that time is expressed in Quotidian: as dates and times (we call this "datetime") and as relative time.


  • 23 January 1967 10:24
  • 23 Jan 1967 10:24:44.393033333004556
  • 23 January 1967
  • 23 January 1967 PM
  • January 1967
  • 1978
  • 1.8 MYA (1.8 million years ago)
  • now (now is the current clock time with millisecond precision)

It is important to note that for Quotidian "1 Jan 1967," "Jan 1967" and "1967" all refer to the same moment, with different precisions. These precisions are used both to format the text representing the time and to calculate the end time of an event if one is not explicitly given. The precisions of these expressions are one day, one month, and one year, respectively.

Datetimes are stored internally as the number of milliseconds and fractions of milliseconds from 1 January 1970 GMT. When editing or printing, a time must be associated with a calendar and timezone.

There are two special ways to represent the end times of events that finish in the future: open time and gott time. Here are some examples:

  • open
  • open (10 years)
  • alive
  • alive (4 weeks)
  • gott50
  • gott95

Relative time

Relative time is expressed as a duration and can be added or subtracted from a datetime to get another datetime. Examples are:

  • 1 year
  • 1 year 4 months 8 days 7 hours 9 minutes 33 seconds
  • 10 weeks
  • 0:04:45 (4 minutes and 45 seconds)
  • 1.2 MY (1.2 million years)

Relative time is used to express accuracy, as an optional way to express the duration of events, and in relative timelines where all events are relative to a single datetime.

The QViewer will not show events that have the same start and end time. Such events have no duration and are effectively invisible. Defining an event that has a start time later than its end time is an error. However, this error may be difficult to catch in the case of relative timelines. See comparing relative times.


Accuracy is the degree to which a measured value conforms to its true value. Precision refers to how much information is given in a measurement. A time value can be very precise but not accurate, for example, "The Battle of Waterloo was fought on 19 June 1915 at 10:30AM." Or it can be accurate but not very precise: "The Battle of Waterloo was fought in 1815." Values can also be both accurate and precise, or both inaccurate and imprecise.

When setting an event's start and end times in the QEditor, a button is shown on the edit panel. This button brings up a dialog box to define the accuracy range of the given time.

dialog for accuracy (and other time options)

(The same dialog can be used to specify a different calendar or timezone than the ones currently set for the editor.) Accuracy is expressed as a duration from the given time both forward and backward, and the true value should be in that range with some degree of certainty. There are three variations:

  • plus and minus zero: Perfect accuracy (this is the default case)
  • plus and minus: The same duration both forward and backward from the given time
  • separate plus and minus: Different durations forward and backward from the given time

Accuracy is visually indicated in the QViewer by the event's color becoming more transparent across the accuracy range. This is computed by adding the plus accuracy duration to the given time to get the latest time, and subtracting the minus accuracy duration from the given time to get the earliest time.

QViewer showing uncertainty about Shakespeare's day of birth

Some special time expressions do not use accuracy. These include: open time, gott time, and now. The QEditor may allow accuracy to be added to these times, but the QViewer ignores it in the current version. This may change in future versions.


Accuracy is the degree to which a measured value conforms to its true value. Precision refers to how much information is given in a measurement. A time value can be very precise but not accurate, for example, "The Battle of Waterloo was fought on 19 June 1915 at 10:30AM." Or it can be accurate but not very precise: "The Battle of Waterloo was fought in 1815." Values can also be both accurate and precise, or both inaccurate and imprecise.

  • 1921
  • January 1921
  • 1 January 1921
  • 1 January 1921 0:00:00
  • 1 January 1921 0:00:00.000000000000000

For Quotidian, these dates refer to the same moment in time. Quotidian saves a representation of that instant, but it also saves how much precision was given in specifying the instant.

In the examples above, the precisions are:

  • year
  • month
  • day
  • second
  • 1 x 10 -15 seconds

The saved precision is used when showing a text representation of the time. It is also used when an event is defined without an explicit end time. In this case the duration of the event is assumed to be the precision.

It is impossible to write a time expression with no precision. "Now" has a precision that matches the millisecond precision of the internal clocks on most computers.


In Quotidian, dates and times are stored internally as the number of millisconds from the first instant of 1 January 1970 UTC. The QViewer does not need any information about calendars or timezones to display events. It does need both a calendar and timezone to generate the display time text, but this is independent of the timezones and calendars set in timeline files.

The QEditor uses timezone and calendars to present and edit time values in ways that are meant to be easy and comfortable for most authors in most cases. Calendars are historical, cultural and religious constructions and it is not always possible to convert even a simple date and time into an unambiguous time value.

It may be necessary for a timeline author to make a series of corrections and assumptions to convert a time expression into one of the standardized time expressions that Quotidian understands.

Quotidian relies on a third-party code library called JODA. JODA knows about these calendars: Gregorian, Julian, Buddhist, Coptic, Ethiopic, Islamic, and ISO. There are four variations of the Islamic calendar: 16 base, 15 base, Habash al Hasib, and Indian. Quotidian currently supports these. Other dates will need to be converted to one of these for the QEditor to understand them.

The Gregorian calendar was adopted at different times in different places, ranging from 1582 into the twentieth century, so the Gregorian calendar in Quotidian comes with a choice of changeover date. Before this date, the Julian calendar is used. This presents problems in non-European countries that did not use the Julian calendar before adopting the Gregorian. Turkey, China, and Japan officially converted in the early twentieth century. In general a simple date will suffice to mark the day when the changeover occured. There is a list of dates and places that can be used to specify which calendar is wanted. It is also possible to add others to Quotidian if one is missing or incorrect.

(see also http://calendopedia.com/modern.htm)

Both the QEditor and QViewer keep track of a current calendar and a current timezone and use these in conversions. It is possible to mix dates and times entered in different timezones and calendars within a single timeline or even within a single event. Each date and time entered in the QEditor can be given a calendar and timezone for later conversions.

Times in events and other places in the editor that are shown without a timezone or calendar (22 Jan 1901) are relative to the timeline's timezone and calendar. Times are shown with an explicit timezone or calendar if that is different from the timeline's calendar or timezone. For example, if the timeline calendar is set to "Gregorian (England and colonies)" and the timezone to "America/New_York," times with explicit values might look like: "22 Jan 1901 10:00 [Europe/Moscow]" or "22 Jan 1901 10:00 [Julian:Europe/Moscow]." A time in the New York timezone and Gregorian calendar would have those implicitly: "22 Jan 1901".


Islamic Calendars

Quotidian uses the JODA-Time library to convert dates and times in different calendars. The following is from the JODA-Time documentation at http://joda-time.sourceforge.net/cal_islamic.html:

The Islamic, or Hijri, calendar system is a Lunar calendar used in many Muslim countries.

The Islamic calendar system is a lunar calendar based on observation. The observation aspect of the calendar means that a new month can only be declared based on human observations of the moon, something which can obviously vary and is unsuited to computer calculation.

Joda-Time implements the arithmetic Islamic calendar, which is an approximation of the actual calendar. There are 12 months, each of 29 or 30 days, making a year of 354 days, or 355 in a leap year. The days in the month alternate, with the first month having 30 days, the second 29 days and so on. In a leap year, the twelfth month has 30 days instead of the normal 29.

The definition of a leap year in the Islamic calendar varies. All agree on a 30 year cycle, however which years within the 30 are leap varies by the leap year pattern:

15-based 2, 5, 7, 10, 13, 15, 18, 21, 24, 26, 29
16-based 2, 5, 7, 10, 13, 16, 18, 21, 24, 26, 29
Indian 2, 5, 8, 10, 13, 16, 19, 21, 24, 27, 29
Habash al-Hasib 2, 5, 8, 11, 13, 16, 19, 21, 24, 27, 30

Joda-Time allows you to choose between these leap year patterns. The 16-based algorithm is the most commonly used, and is the default. Note that Microsoft uses the 15-based pattern, and calls it the 'Kuwaiti algorithm'.

The epoch of the calendar system is 0622-07-16 (Julian) which is therefore 0001-01-01 (Islamic). The current (and only implemented) era is 'AH' (Anno Hegirae).

Days of the week are named 'the first day', 'the second day' and so on, where Sunday is the first day. The day of the week value (numeric) returned by Joda-Time however, is the same as the ISO day of week definition. Thus Sunday will return the numeric value 7, and Monday will return the numeric value 1.

A day in the Islamic calendar begins at sunset on the previous 'day'. Joda-Time does not model this, thus times and date rollover follow standard ISO definitions, in other words starting at midnight.


Timezones are a fairly recent innovation in timekeeping. Before the advent of railroads in the nineteenth century, each locality could keep its own time based roughly on the local solar time.

For Quotidian, timezones are geographical entities that share common timekeeping conventions. The fundamental purpose is to compute the difference of local time to and from Universal Time (based on GMT). This includes how that difference varies by season (Daylight Savings Time in the US, Summer Time in Britain) and how the time difference changed historically.

Timezone changes are made not only by national governments but also smaller regions like Starke County, Indiana, which switched from central to eastern time in 1991 and switched back in 2006.

The code library that Quotidian uses to compute time uses the public tz database. This database changes several times a year and each new version of Quotidian will incorporate changes to this database. More frequent updates can be made if necessary.

Because of the historical dimension, Quotidian doesn't use the standard timezone abbreviations (e.g. EST for Eastern Standard Time) to choose timezones. Instead it uses timezone region names that usually have a continent and a major city the region. For example, "America/New_York," "Asia/Bangkok," "Africa/Algiers". All the names are derived from those in the tz database but some don't fall into the continent/city form: "Various/Israel". Some timezone names don't refer to regions, for example, "Etc/GMT+1".

Quotidian does use timezone abbreviations to distinguish ambiguous times caused by seasonal clock change.

the tz database: http://www.twinsun.com/tz/tz-link.htm

joda timezone update: http://joda-time.sourceforge.net/tz_update.html

ambiguity caused by seasonal clock change

Seasonal clock change (daylight savings time in the US) causes clocks to be moved forward at a particular time and then moved backward at a later time. The first part is relatively easy to handle. The time for the interval disappears and the time expressions using it are invalid.

So, 8 March 2009 2:30, is not a valid time value.

Turning clocks back causes the same time to reoccur immediately. This means that 1 November 2009 1:30 is followed an hour later by another 1 November 2009 1:30. The tz database contains two abbreviations for locations that experience seasonal clock changes. These can be appended to time values to determine which time is being used. With the America/New_York timezone, 1 November 2009 1:30 EDT is followed by 1 November 2009 1:30 EST.

Quotidian displays these abbreviations only for times that fall in the period (usually two hours) each year that are ambiguous.

The abbreviations appear in the Time Options list during timezone selection. There is a pair of abbreviations for each timezone, the first is for the standard time and the second for summer time. For timezones where there are no seasonal clock changes, both the abbreviations are the same.

millions of years

Time can be expressed as millions of years in the future (MYF) or millions of year in the past (MYA). These are based on the number of years from 1970 where years are exactly 365.2425 days. Although it is possible to express very small decimals (0.00001 MYA), this is not encouraged. Dates closer to the present (within 10000 years) should probably use regular datetime expressions.

  • 45 MYA (forty-five million years ago)
  • 1.5 MYF (one and a half millions years in the future)


The word "now" represents the present time in the world outside of the computer. It can be used as a datetime in both start and end times of events. The computer's internal clock is used to update the "now" value each time the QViewer display redraws. Internal clocks usually have millisecond precision, so the precision of the now datetime is always a millisecond. The accuracy of the now value depends on the accuracy of the computers internal clock. However, the QViewer may take a large fraction of a second to redraw a complex view having many events and images. When the time scale is increased, events with now values may appear to lag slightly behind the actual time.

open times

timeline with open events

QViewer showing timeline with open events

There are many events that start in the past and continue into the future. Uncertainty about the future translates into a question of accuracy for the end times of events. By specifying "open", "alive", "exists", or "continues" as the end time, the event can be assigned an end time that has an early value of the present time and a late time of some fixed lifetime. Each of these open times has an arbitrary lifetime of 100 years and represents a high estimate of a human lifespan. Lifetime other than one hundred years can be specified by following the open term with a duration in parentheses.

for fruit flies:

alive (2 months)

for the terms of sitting Supreme Court justices (using the longest historical term, William O. Douglas):

open (36 years)

The QViewer shows an open time as gradually fading from the present time to the given lifetime.

Open times can be thought of as an alternative way to express both the end time and its accuracy.

The event does not end if the present passes the time expressed by the start time plus the lifetime. In this case, the event is shown as ending at the present and will continue to do so until an author edits the timeline to supply a true end time or a longer lifetime.

Events with open times are "open" at the present time. Therefore their start times must be in the past. Having a start time in the future would mean that the start time would be later than the end time. This is because an open end time, in a very real sense, has an earliest value at the present. Although it is an error to have the start time before the end time, it can be self-correcting. Times in the future have a way of becoming times in the past.

gott times

It is sometimes difficult to assign an end time to events representing time periods that are unique or lack historical precedence. Open or alive times are useful for events where there is some actuarial or historical basis for assigning a duration.

J. Richard Gott III, a professor of Astrophysics at Princeton, Wrote a paper about calculating the duration of things for which no record of the longevity of similar things exists.

From Prof. Gott's article [New Scientist, November 15, 1997]:

"In 1969, ... I took a summer holiday in Europe and visited the Berlin Wall. It was the height of the Cold War, and the wall was then eight years old. Standing in its ominous shadow, I began to wonder how long it would last. Having no special knowledge of East-West relations, I hadn't much to go on. But I hit on a curious way to estimate the wall's likely lifetime knowing only its age.

"I reasoned, first of all, that there was nothing special about my visit. That is, I didn't come to see the wall being erected or demolished - I just happened to have a holiday, and came to stand there at some random moment during the wall's existence. So, I thought, there was 50 percent chance that I was seeing the wall during the middle two quarters of its lifetime. If I was at the beginning of this interval, then one-quarter of the wall's life had passed and three-quarters remained. On the other hand, if I was at the end of this interval, then three-quarters had passed and only one-quarter lay in the future. In this way I reckoned that there was a 50 percent chance the wall would last from 1/3 to 3 times as long as it had already.

"Before leaving the wall, I predicted to a friend that it would, with 50 percent likelihood, last more than two and two-third years but less than 24. I then returned from holiday and went on to other things. But my prediction, and the peculiar line of reasoning that lay behind it, stayed with me. Twenty years later, in November 1989, the Berlin Wall came down - unexpectedly, but in line with my prediction."

A similar method can be used to get a 95% chance of being within the predicted range. The range in this case takes the current duration times 1/39 for the lower prediction and the current duration time 39 for the upper. We can use these methods to set the accuracy bounds for end times. I have named these methods (with Professor Gott's permission!) "gott50" and "gott95" respectively. These can appear only as the end time of events.

The gott50 and gott95 values are only useful when applied to events where there is absolutely no information on which to base a prediction about longevity. The lifetimes of humans and other animals are certainly cases where such data does exist and the method should not be used. As a negative example, by the gott95 method the end of the lifetime of a hundred year old man would appear with an accuracy range between two and half years and 3900 years in the future.

Because the end time prediction is based on the time between the start time and the present time, for this method to be useful the present time must have no special relationship to the history of the things being shown. The method is not very useful if the present time is known to be at the start or end time of the event, or if the existence of the event could only be observed at some narrow range in its lifetime.

Like open times, gott times provide a way to add both the end time and an accuracy value. Also, like open times, events with gott times must have their start times in the past.


One way to express duration is by building an expression out of one or more period fields. These fields are years, months, weeks, days, hours, minutes, seconds and milliseconds. The value of all the fields are added together. In period expressions the values for years, months, weeks and days are followed by their field name (either singular or plural). Hours, minutes and seconds are separated by the standard separator for the author's locale (":" in the U.S.) and the larger of these fields must be present to express a smaller one. (12:33 means 12 hours and 33 minutes, not 12 minutes and 33 seconds.)


  • 2 (two hours)
  • 2:33 (two hours, thirty-three minutes)
  • 0:00:0.001 (one millisecond)
  • 10 weeks
  • 10 years 3 months
  • 4 months 0:01 (four months plus one minute)
  • 7 years 10 months 1 day 1:45:33.878 (seven years, ten months, one day, one hour, forty-five minutes and 33.878 seconds)

Periods can be expressed to a maximum precision of one millisecond.

small durations

Smaller durations can be represented the same way as hour, minutes, seconds, and milliseconds are represented in periods, but with additional decimal places for seconds. One cannot mix expressions containing years, months, weeks, and days with expressions with more than three decimal places for seconds. Up to 18 decimal places are allowed.


For even smaller durations, simple decimal numbers are assumed to be seconds and fractions. Up to 18 decimal places are allowed (attoseconds).


long durations in millions of years

The relative time expressed in millions of years (MY) is based on a fixed year length of 365.2425 days.

6.75 MY

It is possible to express very small fractions of millions of years (0.0000001 MY), but this kind of use is not encouraged. Durations shorter than 100000 years should probably be expressed with periods of years.

comparing relative times

The QEditor will try to warn the author when the start time is greater than the end time. It cannot do this reliably for relative times. The current version assumes a 12-month year, 7-day week, 24-hour day, 60-minute hour and 60-second minute when comparing relative periods. This will catch some errors with the possible cost of spurious warnings about relative events that are not errors in practice. The QViewer also checks after origin times are added to relative timelines and it is possible for some events to be drawn or not depending on what origin time is given.

Quotidian assumes that time durations expressed in terms of an hour or less are exactly comparable. Durations expressed using the same terms are comparable (3 days vs. 4 days). Beyond these the problem becomes difficult. Durations change depending on what datetime they are based on.

For example:

  • Comparing 30 days to 1 month depends on the month and calendar.
  • Comparing 24 hours to 1 day will be equal most days, but, in some timezones, once a year days have 25 hours and once a year they have 23 hours.
© 2011 Quotidian Incorporated