Some aspects of dates in a genealogy program

When representing dates in the past, quite a few cases must be considered. The specific requirements of a genealogy program can also cause difficulties. I recently started working on my own genealogy program. This article is not much more than a collection of written-down thoughts I deemed interesting enough to keep.

Some problems

A list of situations, problems and cases one must consider:

Multiple calendar systems exist, like the Gregorian calendar, the Islamic calendar, the Japanese era names, …
One geographic location can use multiple calendar systems simultaneously. For example, some Orthodox churches still use the Julian calendar system, while the Gregorian one is used for civil purposes.
Calendar systems change over time. For example, the Gregorian calendar system was introduced in 1582, and replaced the Julian one.
Calendar systems don’t change everywhere at the same time. For example, Anglo-Saxon countries didn’t switch to the Gregorian calendar until much later.
The start of a new year is not fixed. Nowadays, this is mostly January 1st, but that wasn’t always and everywhere. For example, in the United Kingdom (except Scotland), the new year officially started on March 25th, although January 1st was already in common use.

An example. In our region, the Gregorian calendar was introduced in 1582. The United Kingdom only switched in 1752 (the new year was switched to January 1st at the same time). This means that Januari 30th, 1648 (Julian, old style) is equal to Januari 30th, 1649 (Julian, new style) and also equal to February 9th, 1649 (Gregorian).

A solution

One of the goals of a genealogy program is to reduce errors when collecting data. Therefore, it is recommended to input data (including dates) as found, meaning in their original calendar system.

Luckily, we don’t need to re-invent the wheel. (A lof of) inspiration for the input can be taken from the date functionality of Gramps.

Saving dates as just text might solve the input problem, but it doesn’t help us to work with the dates. Every self-respecting genealogy program will want to sort events on date, or calculate some time ranges (such as the age of someone). This needs to be possible with dates from different calendar systems.

For example, it is not unthinkable that a person was born in our region, with a Gregorian birthdate. This person subsequently marries and gets a marriage date in the French republican calendar (which was used from 1793 until 1806). Finally, this person dies in Russia, where the death date is in the Julian calendar system, as Russia didn’t switch to Gregorian until 1918. However, we still want to calculate the person’s age for all these events.

A possible solution is to convert all dates to the proleptic Gregorian calendar for calculations. This calendar is the Gregorian calendar but is extended backwards te before its introduction. This conversion means you no longer have to account for other calendar systems, different new years or missing days.

Displaying dates in the program

When displaying dates, one option is to always show the proleptic Gregorian calendar. However, this leads to unnecessary interpretation work for the reader, as the Gregorian calendar existed nowhere before 1582.

While displaying a date in the input format is useful, solely relying on it isn’t optimal either. For example, someone with a birthdate of May 12th, 1790 and a marriage date of 1 Floréal II will not arise suspicion. Yet, it should. 1 Floréal II is April 20th, 1794, meaning the person in question isn’t even four years old on their marriage.

A solution I am currently considering is displaying dates before 1582 in the Julian calendar, while dates afterwards are shown in Gregorian.

Hours and timezones are ignored

A huge advantage of genealogy is that the smallest useful unit of time is the day. This means we can ignore the whole problem of timezones and changes to those timezones.

Additionally, doing calculations with historic times is almost impossible. Until the 19th century, most places had their own local mean time, meaning the time when 12 o’clock would be when the sun was at its highest point. Trains and their fixed timetables necessitated a standard time within a region. Knowing what time was meant with, for example, 8:53 AM on May 16th, 1589 in a village in Flanders is almost impossible.

Even with standard time, there are a lot of changes. For example, the Dutch Wikipedia tells us that the Netherlands first introduced a standard time in 1909, which was GMT +0h 19m 32,13s. In 1932, this was simplified to GMT +0h 20m, to finally GMT +2h in 1940 (due to the Germans). In 1941 and 1942, this "daylight saving time" was also in force during the winter. In 1946, it was abolished, to be re-introduced in 1973 due to the oil crisis.

According to Frank De Boosere (Dutch only) the situation in Belgium was different. We already introduced a standard time in 1892: GMT, as Belgium is in the geographical area of the GMT. Between 1914 and 1918, we observed GMT +1h, again due to the Germans (who also employed daylight saving time). In the interbellum, our clock moved one hour: in the winter GMT, in the summer GMT +1h. During the Second World War, we again switched to GMT +1h in the winter and GMT +2h in the summer. Daylight saving time was also abolished here between 1946 and 1977: GMT +1h the whole year round. In 1977, daylight saving time was re-introduced. However, "daylight saving time" is far from a standard definition. Until 1996, daylight saving time ended in the last weekend of September, but this was extended with a month.

Missing or incomplete data

A last peculiarity of a genealogy program is that dates can be incomplete, wrong or uncertain. For example, the month of a date can become illegible, or it was never legible in the first place. A date can also be estimated based on other sources, but without direct confirmation. For example, a death certificate might list the age of the deceased, but not the birthdate. In that case, we can calculate the birthdate based on the age and date of death, but this can always differ by one year. The age is sometimes also just plain wrong.

We thus need to take into account missing data (days, months, years, or multiple) and the certainty of the dates (uncertain, estimate, calculation).