Explanation of YMD Birthdate Calculations

The new version of the birthdate calculator uses two different computation methods:
  1. 30-day fixed-length month (the "8870" system is a variant of this)
  2. Calendar month
It formerly used a third method as well, 28-day months, but this feature was later removed for various reasons.
Despite many vehement claims to the contrary, all three of these methods are to be encountered in historical Y/M/D or Y/M/W/D age (or time-elapsed) calculations. Based on limited evidence, it appears that 30-day-fixed is probably more likely to have been used in later times, but the 28-day month seems at least to dominate arithmetic texts from the early 1800s on back in the US. The calendar-month method seems to have coexisted with both systems, considered to be more correct but little-used due to its relative complexity. It is best to compare the results of the three calculations for known death date, age, and birthdate combinations which approximate the context of the unknown date as closely as possible.

Subtraction Order

There has been some concern as to how subtraction should be done in these calculations. It  does not matter with fixed-month calculations - for those no special considerations are encountered.  For calendar-month calculations, things get complicated
"Borrowing" during subtraction turns out to be the heart of the problem with calendar-month lengths.
Let's examine this by looking at the ways YMD age is calculated to begin with, since what we really want to do is reverse that calculation.  For example, take an age calculated thus:
 
  Death 1988 Apr (4) 6
- Birth 1928 Mar (3) 7

Here, we must borrow from the months place into the days place, since 7 is larger than 6 (ignoring the frightening notion of negative calendar time).  The question is - do you borrow 30 days for the length of April, as might seem obvious at first?  Some will say "yes", some will say "no, borrow 31 days for March."  Which is correct?  At second thought, you'll probably conclude that you should borrow 31 days from March.  Well, as a third thought, consider what I like to call the "anniversarial" calculation, sort of the "common sense" approach to doing this.  Say we want to count back from the date of death, we have 60 whole years from 1988 Apr 6 to 1928 Apr 6, no complete month from Apr 6 and Mar 7, and 6+(31-7) = 30 days.  Counting forward from the date of birth gives the same result for this case.  Note that since we crossed the Apr-Mar month boundary, we borrow from the length of March, as we probably noticed in our second thought on the subject.

Now let's try a different one.
 
  Death 1988 Apr (4) 6
- Birth 1928 Feb (2) 7

We count back from the date of death, so we have 60 whole years from 1988 Apr 6 to 1928 Apr 6, 1 month from Apr 6 to Mar 6, and 6+(29-7) = 28 days.  Now count forward from the date of birth, 60 whole years from 1928 Feb 7 to 1988 Feb 7, 1 month from 1988 Feb 7 to 1988 Mar 7, and 6+(31-7) = 30 days!(!!!)  This is a subtle and critical problem in calendar-month units.
Writing out the age calculation as traditional long subtraction duplicates the forward (from date of birth) anniversarial method, as long as you remember to borrow from the length of the month before the death month.  The backward anniversarial calculation really is like subtracting birthdate - deathdate but (curiously) borrowing from the length of the birth month itself.

Having recognized this complication, we should now ask what method was historically really used?  Did the author of the tombstone (or whatever YMD age medium) count "anniversaries" forward from the birthdate or did that person count back from the death date?  People will often claim that counting forward is the obvious thing to do, but is it?  If you didn't know the results were different, might you count back from the death date?  Or perhaps the author wrote down the problem as a subtraction?  I believe with the long-subtraction approach, we can be fairly confident that deathdate - birthdate would always be used, since the deathdate is in a sense the larger number (the backwards anniversarial calculation can be regarded as giving a negative age - compare the "2s complement notation" used in digital computers).  However, the person writing the subtraction would have to be clever enough to figure out the correct month to borrow from.  For abitrary data, we really can't be sure what approach was used, which introduces an additional uncertainty on top of our uncertainty about what month lengths were used.  I have generally assumed that the forward anniversarial calculation (or its long-subtraction equivalent) should be regarded as the most likely method, but practically speaking, I doubt if it was always the approach used.  This issue tends to confuse, and it seems unlikely that people in the past were any less prone to be confused by it than people are today.

Next, we have to look at how to reverse the forward anniversarial method.  We want to do the subtraction deathdate - age = birthdate.  Let's look at our example again, using the long subtraction form of the forward anniversarial calculation:
 
Death 1988 Apr (4) 6
- Birth 1928 Feb (2) 7
= ---------- ---------- ----------
Age 60 1 30

Remember we borrowed the length of the month before the death month, so what do we do to reverse this?  It's pretty simple - you just use that same length for borrowing (since we already know that subtraction using fixed-length units can be inverted like this), so:
 
Death 1988 Apr (4)  6
- Age 60 1 30
= ---------- ---------- ----------
Birth 60 2 7

And this is the method used by the birthdate calculator.  For those who care, the algorithm itself decrements the death month variable first when borrowing is needed.  Of course, if the month decrements to 0, you have to borrow from the year and add 12 to the month total too, and then that number is the code used to find the month length to add to the day total.

An implication of this is that the birthdate calculator also works to compute forward anniversarial age.  You just fill in the birthdate numbers in place of the age numbers (converting the months to their respective ordinal numbers, 1 for January and so on), although the output sometimes will give figures such as 12 months 39 years for 40 years.

Also, contrary to popular belief, accounting for leap years is not difficult.  You simply add a day to the February length if the borrowed month is in a leap year.
 

Borrowing Approximations in Fixed-Month-Length Systems

The fixed-month systems, despite being mostly free from concerns over subtraction order, have conceptual difficulties in the way they borrow. While year lengths in fixed-month systems are typically given in terms of months and days, the actual calculation of time elapsed in these systems usually seems to neglect the left-over days when borrowing (see The American Tutors' Assistant, J. Crukshank, Philadelphia, 1813 -- Early American Imprints, Series 2, #27718). Since neglecting the days seems to be a common (though mathematically questionable) practice, my fixed calculation functions always drop this term as well, but it is entirely possible that the calculation of age in some instances may have preferred to take the extra days into account.

The Curious 28-day Month

I have no direct evidence of the 28-day-month (with 13-month year) having been used in Y/M/D ages on tombstones yet, but 17th (Cocker's Arithmetick, Edward Cocker, London, 1691.), 18th (The American Youth's Instructor, Daniel Fenning, Dover, New Hampshire, 1795), and early 19-century British and American sources indicate that it was definitely the preferred method for Y/M/W/D time-elapsed calculations and generally preferred for Y/M/D calculations. The use of a 30-day month for calculations in contrast is unattested until the late 1800s so far as I can tell (and I have yet to see any attestation personally, though I've been told they exist). For an age given with weeks, the birthdate calculator can still be used by multiplying the number of weeks by 7 and adding this to the number of days, and then using the 28-day calculation result.

Daniel Fenning notes in his late 18th-century American Youth's Instructor (see above, p. 49):

Though 13 months are said to make a year and servants commonly reckon a month 28 days: yet you are to observe, that in trade, and transacting business by a month is meant a Calendar Month, that is from any day of the month to the same day of the next month: Thus, from the 5th of February to the 5th of March, or from the 18th of April to the 18th of May is a month.

(Fenning's italics - long-'s' and ligatures transliterated.)

This note tells us two extremely significant things:
  1. The 28-day month was then in "common" use, apparently due to its comparative simplicity.
  2. Though the 28-day month was common, "Calendar Months" were considered to be more technically correct, at least by Fenning. However, the frequency of the 28-day month in arithmetic books aimed at practical calculations and the fact that Fenning's own examples use it as well suggest to me that the technically preferred calendar month was probably not used very often, except perhaps in such trivial cases as he cites.
It should also be said that a few of the works noted mention in passing a "solar" year of 12 "solar" months and a "lunar" year of 13 "lunar" months, but these terms are little-used outside the context of simple definition and the lunar month (approximated to 28-days) is still the only one used in computation examples where "lunarity" and "solarity" are denoted. Generally, the arithmetics at least mention the actual length of the year in days and hours but they do little with it. One might perhaps see a glimmer of the 30-day month in the guise of a "solar" month, but none of the sources are really clear whether this is to be considered 30 days or 1/12 of the 365 days and 6 hours in a year.

The identification of the 28-day month in old record beds should be easy though. Approximately 1 in 26 ages in such records should indicate an age of 12 months (1/2 borrow from the years place and 1/13 of those give 12 mos.). Neither of the other systems would be expected to give this result as a matter of course. Ages in weeks, as mentioned, are a good indicator too. Unfortunately, it is not yet clear when the common preferred method changed from the 28-day to the 30-day approximation system. The best evidence so far seems to indicate this would have been in the mid-to-late 1800s in the United States. Data for other regions is so far lacking.

Julian and Gregorian Calendars

The calculator also now allows Julian calendar dates, but you cannot mix Julian and Gregorian dates or ages in the same calculation. Generally, the Julian result will be identical, but there are a few exceptions, namely for certain date combinations which cross century years which are not divisible by 400 (e.g. 1400, 1500, 1700, 1800, 1900, ...). None of around ten pre-1820 sources which I examined even acknowledged the existence of the slight year-length difference, including the usually pedantic and meticulous Fenning, so the chances that people at the time remembered to account for it are small though.

Real-Time Accuracy

Interestingly, the 28-day method is the most accurate of these three in terms of its ability to get time-elapsed. The calendar-month method of course gives a result that is really rather useless for measuring how much real time has passed between two events since the month is not a fixed unit of time in that system. The 30-day does have a month that is fixed, but it normally neglects 5 and 97/400 days while the 28-day only neglects 1 and 97/400 days. Of course, the fact that month units are so inconsistent probably explains why no one uses them for measuring real time anymore. Even the most modest computer systems routinely measure time and date in seconds if not milliseconds (converting to Y/M/D only for the user's convenience). However, this accuracy concern is of no real bearing on the question of historicity.

Why Bother?

Aside from the more general question of "why bother with history," certain people have raised the question "why worry about the calculation method if there is already error from other sources?" When phrased more thoughtfully, this is a good question, but a sad fact of life is that all data contains some degree of error. This does not mean that trying to reduce error is pointless or that all data is useless. The question really should be "how much error is introduced by a wrong choice of calculation method compared to error arising from other sources?"

I can't answer this exactly. For one thing the "other sources of error," which I'll call "inherent error" are likely to vary in frequency and magnitude from source to source. From the few record beds I've seen evidence for, I would roughly guess that the error rate tends to be something on the order of 10% and the magnitude in root-mean-square-error over all samples is around 1 or 2 days (if you don't know what this means, just figure that this is about the size you would expect in a "typical" error). Now the difference between 30-day and calendar-month systems is actually fairly close to this (which also makes me worry that some of the error quoted above may be due to some as-yet unconsidered calculation method) so choosing the correct method between those two is roughly (I know this is far from exact) only a matter of cutting the error in half. The 28-day method is the real joker because it commonly comes up with a month's difference from the 30-day and calendar results and very often shows at least a small difference. I haven't rigorously computed its error contribution, but I feel very confident that it overwhelms the inherent error rate and may be significantly larger than the inherent error magnitude in all but the most error-prone data sources. Therefore avoiding this calculation error can be expected to yield large improvements in the accuracy of calculated birthdates.

By Ben Buckner