Genealogies are build by combining events. An event has a date, a place, and individuals playing a role in the event. Obviously then, dates are a basic building block of any genealogy, and thus of genealogy software.
Yet, even after several decades of genealogy software, few genealogy applications provide the thorough and reliable date support you might reasonable come to expect after such a period.
A genealogy application needs to understand multiple calendars. During initial development, the application can perhaps get away with support for just the Gregorian Calendar, but by the time it is released is should have added at least the Julian Calendar. Support for the Julian and Gregorian Calendar is the bare minimum for Western genealogy.
A mature genealogy application supports not just the Julian and Gregorian Calendar, but the Hebrew and the French Revolutionary Calendar as well.
Together, the Julian Calendar, Gregorian Calendar, French Revolutionary Calendar and Hebrew Calendar make up the GEDCOM Four; the four calendars a genealogy application needs to fully support the GEDCOM specification.
RootsMagic version 4 supports the Quaker Calendar. That’s a nice extra, but to be a truly global, a genealogy application needs to support yet more, including the Persian Calendar, Islamic Calendar, Chinese Calendar, Ethiopian Calendar and Thai Solar Calendar.
Multiple calendar support is not a trivial feature.
User-level calendar support includes the ability to let the user pick a date from a calendar control or at least provide free-form date entry, recognise properly formatted dates, and have the ability to determine whether a properly formatted date is valid or not.
For purpose of comparison of dates to each other, conversion of dates from one calendar to another, or at least to a common base such as Julian Dates Numbers, needs to be supported.
Providing all these features for multiple calendars is a lot of work.
I dare say it is more work than most developers envisioned their entire
genealogy application would be when they started out. I am pretty sure that there sure wouldn’t be a
few hundred genealogy applications if all their creators had realised how complex proper
date support is.
When Evoo Systems decided to rewrite WinFamily 6, they rewrote WinFamily 7 in Microsoft .NET. When Ancestry.com decided to rewrite Family Tree Maker 16, they rewrote Family Tree Maker 2008 in Microsoft .NET.
There are many reasons why Microsoft .NET is an attractive platform for developers, but one minor feature of .NET is of major interest to genealogy software developers; it comes with extensive calendar support.
The Microsoft .NET Framework has a Calendar class, a ready-made component for
use in your own applications, with support for more than a dozen different
calendars.
That Calendar class is complemented by a date class, which supports date
arithmetic. It even supports time zones.
You might think that having all that ready-made stuff is a big advantage, as it allows the developer to focus on genealogy features instead of the basic. It is indeed an advantage, yet it does not allow developers to focus on the genealogy features, as is still not good enough for genealogy applications.
One problem genealogist continually deal with is that they do not have exact dates (yet), only approximate dates, for example an approximate birth date derived from age at marriage. Another thing that genealogist continually deal with is that they do not have a date, but do have a date limit (e.g. first spouse deceased before the date of the second marriage).
In GEDCOM, approximations and limits are indicated with abbreviations; ABT for about
, EST for
estimated
, BEF for before
and AFT for after
.
It additionally supports date periods with FROM and TO and date ranges with BET
and AND.
Date periods are for events or states that last a while, while date ranges
are for events where the exact date is not known. An interesting side note is
that FamilySearch’s own PAF does not support date ranges; every time I try to
enter one, it complains that The date you typed is not standard.
.
The GEDCOM specification additionally supports so-called date phrases. A separate article explains what these are and why the inclusion of that feature in GEDCOM is a design error. All that matter here is that it is not about dates.
A genealogy application needs to be able to compare dates. Nowadays, many developers rely on a library or framework such as the .NET Framework that already offers full calendar support and the necessary date arithmetic, but that date arithmetic is for exact dates only.
A genealogy application must perform date comparison on incomplete date, approximate dates, date limits, date periods and date ranges. That can be build on top of date arithmetic for exact dates, but it still has to be build, and it takes some thinking and quite some testing with border cases to get it right.
One thing genealogy applications must be able to do is handle dates that lack a year; you know the birthday, but do not know how old they are. Applications should handle that gracefully. Applications should not assume that the absence of a year implies year zero, but should treat year zero as the absence of year information. Even applications as old as Legacy 7 still get that wrong.
In practice, most genealogy applications do not provide proper date arithmetic, most likely because its developer underestimated the complexity, or never even considered the need for date arithmetic.
Calendar support and date arithmetic are two things many genealogical developers seem to never have thought of when they planned the development of the next great genealogy applications to replace all other genealogy applications.
The practical problems I still encounter trying to using even the very latest genealogy applications make it clear that supporting these capabilities is not high on the priority feature list of most genealogical developers either.
That may sound bad already, but the real problem is that these things should not be on a feature list at all.
Calendar support and date arithmetic are basic capabilities that are part of the very foundation of any properly designed genealogy application. You simply cannot build a good genealogy application without these capabilities, yet even after two decades of genealogy software, many vendors still seem to treat calendars and date arithmetic as minor, nice-to-have and low-priority features.
It is high time all genealogy application vendors start treating calendars and date arithmetic as the basic must-have fundamental capabilities they are.
Copyright © Tamura Jones. All Rights reserved.