OpenHistoricalMap/Tags/Proposed/Tag:start date=datespec
Introduction
The current specification for a date/time spec on the Key:start_date wiki page is satisfactory for current OSM usage requirements, but can be significantly improved for OHM usage. This proposal outlines a new approach which deprecates some current (but rare) usages in favor of a more systematic, standards based approach.
Replace specification of ISO 8601-01 with EDTF
the start_date wiki page specifies ISO 8601-01 as the basic time format. It is not explicitly stated, but all examples on the page use extended rather than basic 8601-01 format (e.g., they have hyphens between year, month and date.) No examples involving time are given. ISO 8601-01 includes a way of describing a date/time interval, but the start_date wiki page does not acknowledge this and provides a different syntax for specifying intervals under the Approximations header.
The bulk of the start_date page appears to date from before the efforts by the Library of Congress and later the ISO to develop specifications for imprecise and/or uncertain and incomplete time and date data. The LoC launched the EDTF (Extended Date Time Format) effort in the 2010s, and the ISO subsequently picked up the work, revising it significantly and producing ISO 8601-02. The Library of Congress would subsequently revise their EDTF draft, producing a compatible subset of ISO 8601-01 and -02 (current EDTF document). EDTF is publically accessible on the LOC website and without IP restrictions. By comparison, ISO standards in general are behind paywalls. This does not make them bad standards but does make them somewhat less open. The primary source of ISO 8601 knowledge appears to be manual sections from the XML, Java, or other language specs and not "real" copies of 8601-01. Presumably the authors of these language standards did reference proper copies of the standard (I have been developing for decades using manuals that cite ISO 8601 and I've never seen an actual copy of the standard.)
The proposed change is to specify EDTF as the standard, mentioning that it is a compatible subset of the relevant ISO standards, and specify level 0 and level 1 are to be supported. This allows replacement of all the ad hoc notations and formats in the Approximations section of the start_date page. Since these are probably not all that commonly used, and likely not supported by current data consumers, this should not be a massive disruption.
Permit Specification of both Date and Time
Event data can contain times as well as dates. Recording complete information when available is good practice. There are currently limits to the granularity of the timeline in the OpenHistoricalMap website rendering engine, but there may be other data consumers that can use more granular data, and the website rendering engine might change at some point in time.
Time Zones
This proposal does not address time zones. Time zones are a concept introducted in the 1800s to assist railroads in setting up and managing time tables. Prior to time zones, local time was frequently referenced to the nearest large settlement. Time zones are not currently mapped in OpenHistoricalMap. Mapping them and integrating them with time processing is likely to be a fairly involved project, should it ever be undertaken.
Deprecate and replace ad hoc specifications on the start_date page
EDTF has levels. OpenHistoricalMap should support EDTF level 0 right from the start and aim to support level 1. These levels provide for both intervals and for degrees and types of uncertainty. Much of this duplicates many of the ad hoc specifications on the start_date page. The following table shows the mapping between the ad hoc conventions on the start_date page, the comparable EDTF specification, and an explanation of the application.
| Existing | EDTF Proposal | Description |
|---|---|---|
| ~1855 | 1855~ | (some time around 1855) |
| 1860s | 186X | (during the 1860s (i.e 1860 → 1869 inclusive)) |
| ~1940s | 194X? | (probably during the 1940s) |
| 480 BC | -480 | (for something that happened in that year) |
| before 1855 | ../1854 | (during 1854 or before) |
| before 1910-01-20 | ../1910-01-19 | (before a specific date - possibly when a photo was taken) |
| after 1823 | 1823-01-01/.. | (after 1 January 1823 - possibly based on the year in which a map was produced) |
| C18 | 17XX | (during the 18th century) |
| mid C14 | 135X? or 134X/136X | (some time during the middle of the 14th century) |
| late 1920s | 1925/1929 | |
| ~C13 | 12XX~ | (probably in the 13th century) |
| 1914..1918 | 1914/1918 | indicates some time during WW1. |
| 2008-08-08..2008-08-24 | 2008-08-08/2008-08-08 | indicates some time during the Beijing Olympics. |
| mid C17..late C17 | 1640/1699 | |
Julian Dates
The date component of a datetime spec prefixed with j: will be interpreted as a Julian date. The jd: prefix will be handled in the same way as the current start_page specification.
Other non-Gregorian Dates
Other date types can be supported using the prefix system in a manner similar to Julian dates. Potentially supporting various Asian date formats has been discussed.
Advantages/Results of This Change
- shift to a nearly completely standards based notation
- insure reliable machine parseabilty of dates by entities such as the OHM time slider
- allow precise specification of imprecise and/or uncertain data as often arises in historical research