Dates & Time
There is no one way to measure time - historians know this almost intuitively. And while computational methods for time vary considerably, finding an adequate system to allow for cross-cultural chronometry is not as straightforward as it might seem. Yet it's crucial for ensuring that the events historians document have as close an approximation of time as close as possible to how time is recored in a source. Many computation systems and languages use an integer-based measurement of time known as the Unix-time stamp, or epoche time. The timestamp constitutes the number of seconds from 1 Jan 1970 00:00:00 GMT. Even so, the timestamp, as a datatype, runs out on 16 Jan 2038, and is invalid for dates prior to 13 Dec 1901. Nevertheless the timestamp provides an integer-based means of translating between different calendars and time, across numerous platforms. Nanohistory uses a similar interger-based solution for measuring time: the Julian Day. Julian Days are used by astronomers as a means for tracking celestial bodies. There are also several code libraries which allow for their translation into different calendars - which means, by storing dates in Julian Days, Nanohistory can quickly and easily move between and handle multiple (and often overlapping) calendar systems.
Nanohistory uses Julian Days for dating, and transforms them into calendar dates as required. Julian Days are used in astronomy, and remain consistent across calendar changes, like the switch from Julian to Gregorian. They also permit transformations of Gregorian and Julian dates into Jewish, Hijra (islamic), and French Revolutionary calendars, and vice versa. This permits scholars working with different calendar systems in different texts, to reconcile dating across different cultures and contexts. Each date is stored as a number (11 January 2019, for instance is 2458494.5). Dates can be in-exact or ambiguous: users need only indicate a year, or a year and a month, and the platform will create a date range. Say an event occurred in Nov 1340 (julian): Nanohistory will note the date as a Julian range from 2210797.5 for 1 Nov to 2210826.5 for 30 Nov. This allows for fuzzy dating, rather than fixed dates for historical phenomena. This dating method allows Nanohistory a much richer, and more nuanced approach to cross-calendrical timelines. GIS Coordinates, for instance, can be associated with dates, allowing users to track changes in spatial data associated with a place name.
Importantly, Nanohistory allows users to assign any number of dates to any entity, and does so by noting start and end dates, which can in themselves be a range or ambiguous. Say a source only mentions a year like 1243AD - this is translated using the Julian calendar functions into a range of 2175063.500000 (Jan 1) to 2175427.500000 (Dec 31). More precise dates create a smaller range. Users can vote for confidence in a particular date, allowing one to rise as authoritative over others. Equally, in using data in searches and tools, users can select fuzzy or narrow dating. Fuzzy selects the widest date range possible from all associated dates, while narrow selects the smallest range. By using Julian Days Nanohistory can quickly filter data according to dates using simple techniques, and present data in a calendar selected by a user. Nanohistory permits the mapping of Geospatial data, which it binds to dates, permitting users to document how named places change over time.