We do NOT know the past in chronological sequence. It may be convenient to lay it out anaesthetized on the table with dates pasted on here and there, but what we know we know by ripples and spirals eddying out from us and from our own time.
The Date entity is used to record a single day in history, a day being the shortest period of time that the database can record. The simplest way for a computer to keep track of time is to count the number of days from a fixed point in history, and this is how the database operates. The starting point for the database is Monday 1st January 4713 B.C.E. (Julian). This is day zero for the julian day, the astrological day numbering system. So good news for those of you who can trace their family back the the Ancient Egyptians.
The date entity copes with uncertainty by recording both a date [jdn] and a range [range] of days which my be zero. It is probably easier to consider the entity as a start date [jdn] and end date [jdn+range]. The set of flags [type], "Before", "On" and "After" are used to indicate how the start and end dates are to be interpreted.
|0||0||1||After 19 Sep 1948|
|0||1||0||On 19 Sep 1948|
|0||1||1||On 19 Sep 1948 or after|
|1||0||0||Before 19 Sep 1948|
|1||0||1||Not 19 Sep 1948|
|1||1||0||On 19 Sep 1948 or before|
|1||1||1||About 19 Sep 1948|
Consider the time line is divided into three sections by the start and finish dates. The type flags are used to indicate how these periods are interpreted. These flags can be used in combination - but where the central period is not zero and the On flag is set this may lead to some ambiguity. So the assumption is made that in these cases that the central period is more likely than the other (Before or After) periods.
The database will keep a record of the calendar scheme that the date was originally recorded in [record_sch] (where known) as well as the preferred scheme normally used to display the date [display_sch]. The concept of a calendar scheme covers the Julian and Gregory calendars as well as the short lived French Revolutionary Calender and other world styles. It will also extend the concept to country schemes, which will cover the change over from the Julian to Gregory calendar. So the English Calendar scheme which follows the Julian Calendar up until 2nd September 1752, when the change over to the Gregorian Calendar occurs. It will also take into account the 25th March new year in England.
There may be occasions when it is not possible to interpret a particular date, either because the system does not yet cater for that scheme or the scheme cannot be determined. In this case the date is held as a text description [desc]. Such dates cannot be sorted and so will normally appear at the beginning of a date sorted list.
Very often documents contain relative dates, commonly in the form of a persons age. In modern western cultures a persons age is invariably given as the age in years on their last birthday. It follows that if you have a document with a persons age and you know when the document was created, you have the persons date of birth to within a year (or if the documents date is uncertain, then that date's range uncertainty range plus a year). By recording a relative date, it is possible to record the exact nature of the original information. Also, if it is found necessary to change the original base date, all relative dates that rely on it will automatically be updated as well.
When recording Events, it is possible enter two date for those occasions were an Event is spread over a period of time. If the start date is uncertain but the duration is known this can be difficult to describe using dates alone. However, if the end date is recorded as relative to the start date, this information can be recorded with all information still being held in a uniform way.
The details of a relative date are held in a separate table which is linked to by the calculated date. In all other respects it behaves exactly as a fixed date, including being used as the base date for another relative date.