OpenHistoricalMap/Dates And Times

Open Historical Map currently supports mapping ISO format Gregorian Dates into an internal format. This supports the Time Slider feature. There is considerable interest in other features (e.g. non Gregorian Dates, date comparators in editors, etc.). We need to start developing requirements and plans for proposed extensions and describe how they will fit into the OHM architecture.

Please use the discussion tab to share your thoughts.

Current Implementation

Currently, the Open Historical Map timeslider operates on a "decimaldate" field that relies on the date functions described here: https://github.com/OpenHistoricalMap/DateFunctions-plpgsql As stated there, the intent is to be able to represent very large dates such as 100,000 BCE in a numeric fashion so they may be compared using simple mathematical filters such as <= and >= Underlying libraries tend to have a limited range of dates, and to have trouble calculating beyond the Unix epoch or Julian day 0. Note that current limitations of the timeslider do require every entity in the vector tiles to have a single start and end decimaldate, so even uncertain dates or ranges would have to be resolved into a single date for filters, but conversion to decimaldate is intentionally done at the point of ingesting for tiles, so that the source data can be retained in its original form.

As of December 2020, functions are provided to work with these two broad issues in date information contributed to OHM:

• Representing dates as a universal numeric format, which can exceed the typical epoch bounds. Representations such as Julian day and Unix epoch have limitations which would not cover pre-historic times such as 25,000 BCE. Thus, the decimal date representation in which the year is kept as-given and the month-and-day are converted into a decimal portion, yielding dates such as -44.796448 (March 15, 44 BCE). This is similar to the R decimal_date() function, except that it does not convert to an epoch and therefore works with extreme dates.
• Expanding partial dates such as 2000 for use as filtering "bookends". When 2000 is used as a starting date for filtering we want to treat it as 2000-01-01, and when used as an end date for filtering we want to treat it as 2000-12-31 By "casting" these partial dates as full dates for each specific use case, we can treat these partial dates as a filter-capable range of dates, without requiring the contributors to supply "false accuracy" such as manually entering "-01-01" onto their dates.

In principle, additional functions could be added to that repository and implemented into the tile creation process, to better represent various types of dates that editors want to attach to their data.

General Requirements

MUST and SHOULD are used in the sense of IETF RFCs.

• Values for Date/Time fields used by OHM MUST be machine parseable and syntactically unambiguous.
  • regular expressions and/or grammars SHALL be published and SHOULD be designed so they are usable by readily available libraries in the relevant implementation languages. [regular expression libraries vary wildly in what they support. If stand alone regular expressions are used, Perl compatibility is probably the most reasonable target.]
• The format of values MUST be easily extensible as alternate dating methods are added (e.g. Julian dates, Asian dating systems)
• Implementations and any supporting software (e.g., overpass time comparator and editor extensions/plugins) SHOULD be consistent in behavior
• Uncertainty in dates SHOULD be considered in the design of formats.
• The design SHOULD be based on existing standards when possible.

Reference Material

• ISO 8601 dates

• Extended Date/Time Format (Library of Congress)

• start_date=* describes numerous things that have the potential to appear, many of which are currently unsupported. This page should be considered when planning future OHM work. ISO 8601-02/EDTF present standard based alternatives to some of the suggestions on the start_date=* page.

• Wikidata Help:Date

• Help:Type_Date

• Proleptic Gregorian calendar

• Julian calendar

• Julian Day

• Proleptic Julian calendar

• Roman calendar

• Chinese calendar

• Vietnamese calendar

• Calendars in general

• Example of a genealogical UI date implementation

• Julian/Gregorian date conversion

Gregorian vs. Julian

The Julian calendar was introduced in 46 BC as a reform of the Roman calendar.

The Gregorian calendar was introduced in 1532 AD as a reform of the Julian calendar.

It is not sufficient to interpret pre 1532 dates as Julian, as the Julian calendar is still in use in some parts of the world, and the proleptic Gregorian calendar projects Gregorian dating backwards from 1532. Additionally, adaptation of the Gregorian calendar was spread out over hundreds of years. Greece, for example, adapted the Gregorian calender in 1923.

Some sort of prefix or suffix system is needed so that Julian dates can be distinguished from Gregorian dates when present.

• Adoption of the Gregorian calendar

Affected software

Decisions about Date & Time formatting affect the following software entities. This list is not necessarily complete.

• OHM Tile Rendering engine
• ID Editor extensions (potential)
• JOSM Editor plugins (in development)
• Overpass extensions (date comparators) (potential)

Experimental Parser

An EDTF parser is being built using ANTLR. The current plan is to implement Level 1 of EDTF with a Java target. The parser currently compiles without error but has not yet been tested. When complete, this parser will be made available to the community under the three clause BSD license, via OHM github.

JOSM Plugin

Al Dimond has developed a JOSM plugin. It currently uses an ad hoc parser, but plans are developing to adapt it to use the ANTLR parser described above.