A Calendar for Your Date — Part II

In A Calendar for Your Date — Part I, I gave a brief tour of the variations in current and historical calendar systems. I now want to approach the question of how we should represent dates that are not expressed according to our Gregorian calendar.

The different calendar systems may be categorised as follows:[1]

Empirical. The start of the months or years is determined by direct observation and intercalary days or months are inserted on an ad hoc basis.

Calculated. These are rule-based and so are predictable. Lunisolar and Solar calendars may be astronomical rather than arithmetic in that the start of months and years may be determined through astronomical calculation rather than purely by using a fixed rule. Calendars with “wandering years”, such as the Egyptian civil calendar and the Mayan calendar, have a simple fixed number of days per year.

Conversion between calculated calendars can be approached algorithmically, if enough information is known, but empirical calendars require the use of tables, and it is rarely the case that enough historical information survives to make this an accurate process.

In general, when we see an historical date, we cannot always convert it directly and unambiguously to our modern Gregorian calendar; it requires some interpretation, and that in turn requires information about the actual calendar variant that was being used, the social group involved, their political and religious leanings, the weather, and maybe even the geographical coordinates.

As a modern-day analogy of this problem, consider if I’d written the date 9/6/2015. Now did I mean June 9^th or September 6^th? If the date had been written in the US then you might believe that the latter alternative is more likely. However, some knowledge of the author, and the fact he has worked in the US but that he is English by birth, might suggest the former alternative is more likely. Hopefully, you see the problem: the converted value cannot always be faithful to the original source information, and it might require an update based on the analysis of new information, or the availability of a revised algorithm or tables.

A number of resources exist for calendar conversions — both algorithms and documentation — although some seem to have disappeared since I first saw them:

URL	Description	Status	Notes
http://historycal.org/	Converter for historical calendars
http://astro.nmsu.edu/~lhuber/leaphist.html	Calendars and Their History	Currently inaccessible	See "inexact" in sec 1.3 observational calendars
http://emr.cs.iit.edu/~reingold/hindu-paper.pdf	Indian Calendrical Calculations
http://www.calendarhome.com/calculate/convert-a-date/	Convert a Date
http://www.cc.kyoto-su.ac.jp/~yanom/pancanga/	Pancanga (version 3.14)

These resources involve specific calendar variants that would have to be known in advance, and at least one acknowledges the inexact nature of general calculations. In effect, a calculated date can never be more accurate than the original, and there will be many cases where it will be less accurate.

What I’m suggesting is that wholesale conversion of historical dates to the Gregorian calendar is a very bad approach for genealogy, and for historians in general. Obviously we need the ability to put dates from different calendars on the same timeline, but that does not mean discarding the original information in favour of a calculated alternative; a process which may involve an increased degree of uncertainty or imprecision (as differentiated in Warm Fuzzy Dates), as well as some loss of evidence. Furthermore, if software is going to collate these dates then it needs a representation that it can understand, and we cannot suffice with just the written evidential form and the calculated variant.

Let me explain what this last sentence means by using a small example. STEMMA applies a bilateral approach to all data items assimilated into a computer-readable form, as explained in Returning to Normalised Names and Dates and in Is That a Fact?. What this means is that it holds a transcript of the original evidential form and a separate computer-readable (normalised) form. A computer-readable date would be used for sorting and collation, but also for generating a display form — say for a report or a chart — according to the regional settings and personal preferences of the current end-user. For instance:

Evidential form:     25 Dec 56

Normalised form:     1856-12-25

Display form:        25^th December 1856

There are a couple of points to note in this simple Gregorian example. Firstly, those software developers who believe that it is possible to automatically convert written (Gregorian-)dates to a normalised form (ISO 8601 in this case) would probably have interpreted this date as 1956 rather than 1856, thus emphasising the importance of the context of the information. I could have used an evidential form such as “Christmas 56” to hammer that home but I wanted to give a sense of its subtlety. Similarly, an evidential form of “my birthday” is also referencing a date, but whose birthday, and in which year — all of which is contextual information that a researcher would use to apply a conversion. My second point is that the display form is generally (in modern software) produced according to a “short”, “medium”, “long”, or “full” request, and that request would examine the end-user’s settings in order to generate a consistent representation for readability. This is an approach that could be applied to all calendars, in principle.

In the case of a calendar conversion, a missing item would be a normalised value in the alternative calendar; one that must be flagged as being “calculated” to avoid ambiguity. The next example includes a date from the French Republican calendar converted to the Gregorian calendar..

Evidential form:     18 Brum an VIII

Normalised form:     #FR#08-02-18

Display form:        18 Brumaire An 8

Normalised form:     1799-11-09         (Calc)

Display form:        9th November 1799  (Calc)

The normalised form is the STEMMA one since there is no standard that I am aware of. The associated display form uses Arabic year numbers rather than Roman numerals. Coinage of the time often used these rather than the Roman numerals used elsewhere, but it would obviously be a display setting. The two extra fields show the equivalent normalised date after conversion to the Gregorian calendar, and its associated display form. The two normalised forms are therefore distinct in that one is a direct implementation of the evidential form whereas the other is a derivation. The second should therefore be flagged as a calculated datum using something akin to the GEDCOM CAL flag (see DATE_APPROXIMATED in the specification). STEMMA would allow the two forms to be bound using the DATE_ENTITY that’s also used for synchronised dates (i.e. its generalised form of dual dates).

Unfortunately, there are no data standards to accommodate the normalised representation of dates in other calendars. All we have is the ISO 8601 date standard[2], which is specific to the Gregorian calendar and largely the result of an amalgamation of previous standards. Much of its content gets ignored in favour of the pure representation of a Gregorian date and/or time, and that includes ranges, ordinal dates, etc. A critique of that standard may be found at: Is the ISO Date Standard Bad?.

GEDCOM 5.5 includes a small set of “date escapes”[3] that can prefix a date value in order to address different calendars:

@#DGREGORIAN@ — Gregorian calendar

@#DJULIAN@ — Julian calendar

@#DHEBREW@ — Jewish calendar

@#DFRENCH R@ — French Republican calendar

@#DROMAN@ — for future definition

@#DUNKNOWN@ — for unknown calendars

This sounds like a step in the right direction although the specification offers little help on the encoding of year numbers or month names for the non-Gregorian calendars. It does acknowledge the ambiguity of using words rather than numbers via the statement: “No future calendar types will use words (e.g. month names) from this list: FROM, TO, BEF, AFT, BET, AND, ABT, EST, CAL, or INT”.

In February of 2015, Bob Coret analysed the usage on this calendar feature in a sample of 82.9 million DATE lines from about 7000 GEDCOM files.[4] He reported the following very low permille (i.e. tenths of a percent) usage — all others being zero:

@#DJULIAN@        0.123 ‰

@#DHEBREW@     0.013 ‰

@#DFRENCH R@  0.006 ‰

Clearly this feature is very underutilised, but what is the reason? Is it that few people have dates in alternative calendars, or that they only store the Gregorian equivalents, or that their software does not support this feature?

Family Historian uses a “[J]” prefix for entering dates in the Julian calendar, and this has also become a display option in some other products (e.g. TNG). For instance: “[J] 1 Mar 1740”. A consequence is that this alternative syntax occasionally creeps into exported GEDCOM dates to dirty the water.

The Unicode Common Locale Data Repository (CDLR) has also proposed a set of calendar names for computer use at: http://unicode.org/repos/cldr/trunk/common/bcp47/calendar.xml, although I cannot see any details of corresponding date encodings. It appears to be part of an extension to BCP47 ("Tags for Identifying Languages") called RFC6067 for "subtags that specify language and/or locale-based behaviour or refinements to language tags, according to work done by the Unicode Consortium”.

The MARC Extended Date/Time Format (EDTF) makes no mention of calendars as it is applicable only to the Gregorian calendar.

The Society of American Archivists (SAA) adopted DACS (Describing Archives, A Content Standard) in 2004. This mentions alternative calendar systems but only from a written point of view as opposed to a digital one. Their Standards for Archival Description, Chapter 7 (Codes), does mention the Julian calendar but only in the context of ordinal dates.

The MSS Working Group discusses a number of issues related to date/time representation, including dates from non-Gregorian calendars.

The ISO 8601 standard that addresses the Gregorian calendar has a few attractive core features:

• It uses fixed-length all-numeric fields and so avoids language issues and textual ambiguties (see GEDCOM list of avoided names, above).
• The resultant text is implicitly sortable without the host software having to understand dates at all.

Ideally, any standard for the computer-readable date formats in the other calendars should adopt a similar approach. This was STEMMA’s goal from its inception. However, it found that it had to adopt a variation of the ISO 8601 format in order to support missing levels of granularity (such as yearly quarters) and to correctly sort differing granularities with respect to each other — two criticisms in the aforementioned article. Apart from the easy cases of the Julian and French Republican calendars, it has made no further headway. What it has done, though, is to create a generic Date entity that can be back-filled with the encodings for any number of calendars — once they’ve been defined — and without changing its overall data model. This is an approach that I strongly recommend to FHISO in order to avoid prematurely dismissing this issue, and then later finding that some method of date escapes is required, similar to GEDCOM.

A number of papers were received by FHISO on the subject of calendars, and their approaches and coverage appear to be very constructive. At the time of writing, there was no associated Exploratory Group established for research into this field.

CFPS	Title	Description
102	Proposal to support dates BC as negative years	This paper presents a case for allowing dates BC to be recorded using the standard Julian and Gregorian calendars, proposes a representation for such dates that is naturally sortable.
67	Proposal to extend the calendar style mechanism of CFPS 43 into an abstract formatting model	CFPS 43′s style mechanism is extended into abstract formatting model that would allow applications to format correctly dates written in many unknown calendar systems.
44	Proposal to support the Julian calendar similarly to CFPS 17	Proposal for a Julian calendar with years starting on 1 Jan
43	Proposal to add style to the wholly-numeric representation of dates in CFPS 13	Proposal to separate presentation from representation in calendars in order to avoid a proliferation of calendars.
38	Proposal for compound calendars to resolve a difficulty with default calendars	Proposal to allow the default calendar to be dependent on the date.
14	Proposal for a Generalised Dual-Date Representation	Proposal for a generalised dual-date representation that applies to multiple calendars
13	Proposal to Accommodate Alternative World Calendar Systems	Proposed adoption of a date syntax applicable to multiple world calendars, both historical and modern-day.

A question I have heard before is why those uncertainties and inaccuracies should be relevant to genealogists. What difference does it make if you’re a few days out, or a month, or possibly even a year? I entirely disagree with this thinking. Even if you’re only building a family tree then the relationships and vital events might not be supported by direct and non-conflicting evidence; there may have to be some interpretation, and some correlation with information from elsewhere in order to justify them.

A bigger question people may pose is why the historical calendars are of interest to genealogists. After all, there is at least some agreed synchronisation between the six principal calendars that are in use today. Not many people can trace their lineage back to, say, Caesar. Well, even historical characters had lineage, and family history, so whether you’re studying modern genealogy or ancient genealogy should be irrelevant. More than this, though, I do not consider genealogy (including family trees and family history) to be a special case that needs its own standards and methodologies. It is a form of micro-history, which in turn is a form of history. The information that we uncover and analyse in our research does not come from a world of its own, and it cannot be considered in isolation. All those events — both large-scale and small-scale — relate to the real world, and will affect each other. Historical research needs a consistent scheme that respects the integrity of our sources and the information found therein. To suggest that software standards, or the Internet, or populist genealogy products, must stick to Gregorian dates would be a case of the tail wagging the dog.

---

[1] E. G. Richards, Mapping Time: The Calendar and its History (1998; reprint, Oxford University Press, 2005), p.99.

[2] Data elements and interchange formats — Information interchange — Representation of dates and times, International Standard, ISO 8601:2004(E), 3^rd ed. 1 Dec 2004; online copy obtained from http://dotat.at/tmp/ISO_8601-2004_E.pdf (accessed 11 Jul 2015).

[3] Actually, version 5.3 also contained this feature but version 5.4 omitted it with the following explanatory statement: “The Lineage-Linked GEDCOM Form is restricted to Gregorian calendar forms. This version of GEDCOM chose not to support multiple calendars. The reason is that support of multiple calendars would require each receiving system to handle multiple calendar conversions”. Source: Tamura Jones, "FamilySearch GEDCOM Specifications", Modern Software Experience (http://www.tamurajones.net/FamilySearchGEDCOMSpecifications.xhtml : accessed 19 Jul 2015).

[4] Bob Coret, "Usage of calendars in GEDCOM", Bob Coret in English, posted 5 Feb 2015 (http://blog-en.coret.org/2015/02/usage-of-calendars-in-gedcom.html : accessed 19 Jul 2015).