a Lightning talk from SOTM US 2022 on how representation of time in OpenHistoricalMap is evolving. DIscussion of ISO 8601-01 and 8601-02, and Library of Congress Extended Date Time Format (EDTF)

1. The State of Time in OHM
• Currently using the formats described on the OSM start_date page
• And of course we support end_date
• Date granularity is not limited by the database
• Should be able to use any timestamp in ISO 8601 extended format
• (don’t use basic format and expect it to work, not that anyone is likely to do
that)
• Note that ISO 8601 is a little bit of a can of worms

2. The State of Time in OHM
• About 2 years ago we got the new Vector Rendering engine with the time
slider
• year by year granularity
• improved version now
• a move to day-by-day granularity is in the offing with a much more capable
time slider
• Note that the DB should be treated as a Database of facts, including dates and
times which are as precise as can be documented

3. The Time Slider

4. Uncertainty and Imprecision
• Frequently we cannot precisely nail down start and end dates
• Maps and aerial photos mostly provide “point in time” dates
• Document what we know
• Currently we are using OSM start_date formats
• OSM refers to ISO 8601 but then defines an additional ad-hoc set of
notations for intervals, imprecision and uncertainty
• ISO 8601 has since been extended with its own notations for the same

5. Uncertainty and Imprecision
• Library of Congress EDTF (Extended Date Time Format)
• An official profile of ISO 8601-01 and 8601-02
• newer than most of the date formatting discussion on the start_date page
• EDTF is a well defined, open and publicly available standard
• https://www.loc.gov/standards/datetime/

6. Alternate Formats
• There has been some discussion of other formats that should be supported
• Other International, such as various Asia-Pacific date schemes
• Julian and Roman
• likely solution is a prefix with a :, when absent Gregorian is assumed
• Julian and Gregorian overlap
• The changeover took centuries
• Roman (pre Julian reforms) will require lookup tables, there is no formula

7. EDTF not supported
• Not officially adapted yet, although leaning that way
• Temporary hack
• put a supported time, possibly incomplete, in start & end date
• use start_date_edtf and end_date_edtf to contain a well formed EDTF date
specification

8. Quick EDTF Tour
• Intervals
• 2022-03-31/2022-04-02
• Precision
• 201X
• 2010-03-1X

9. Quick EDTF Tour
• Uncertainty
• 2010? (may be 2010 but uncertain)
• 2010~ (approximate)
• 2010% (both uncertain and approximate)

10. Quick EDTF Tour
• More Intervals
• 2010/.. (open ended)
• ../2010
• 2010/ (unknown end of interval)

11. EDTF and start_date (or end_date)
• start_date_edtf=2010/2012
• start date is 2010, 2011, or 2012
• start_date_edtf=2010/..
• earliest possible start date is 2010