How Age Is Calculated

Age seems like it should be the simplest calculation there is. You have a birth date, you have today's date, you subtract. In practice, ask three different tools for the same person's age in months and days and you can get three different answers — and none of them is necessarily a bug.

The disagreement comes from a genuine ambiguity in what a "month" means. This guide sets out exactly where the ambiguity lies, what the sensible conventions are, and how to choose the figure that answers your actual question.

Two different questions

When someone asks "how old are you", they might be asking either of two things, and the answers are not interchangeable.

Calendar age counts anniversaries. You are 36 years old because 36 birthdays have passed. Add months and days and you get a position relative to the calendar: 36 years, 3 months and 11 days. This is how people speak, how forms are filled in and how legal ages are defined.

Elapsed duration counts units of time. You have been alive for 13,248 days, or roughly 1,144,627,200 seconds. This figure is completely unambiguous. It is also useless in conversation.

Calendar age is the harder of the two to compute, because it is measured against a calendar whose units are not uniform. Days are uniform. Weeks are uniform. Months are not, and years are only nearly so.

The month-end problem

Here is the case that breaks naive implementations. Someone is born on 31 January. What is their age on 28 February of the same year?

The obvious approach — subtract the components separately — produces nonsense. The month component gives 2 minus 1, which is 1. The day component gives 28 minus 31, which is negative three. You cannot have negative three days, so the code has to borrow from the month, and how it borrows determines the answer.

There are two defensible conventions:

• Day clamping. Advancing one month from 31 January means moving to the same day number in February, or the last day of February if that day does not exist. So 31 January plus one month is 28 February, and the answer is one month and zero days.
• Day counting. One month has not fully elapsed because 31 February never arrived, so the answer is zero months and 28 days.

Day clamping is what most programming date libraries do, and it is the convention behind the major calculators people compare results against. It has the practical virtue of never leaving you a fraction short of an anniversary that cannot occur.

The consequence you need to be aware of is that a "month" is then not a fixed span. Watch these three results, all reported as exactly one month:

A span of 28 days and a span of 31 days are both "one month". That is not a defect in the calculator; it is what the word means on a Gregorian calendar. It is also precisely why contracts that care about exact periods specify days rather than months.

Leap years and the 400-year rule

A solar year is about 365.2422 days. The Julian calendar approximated this by adding a leap day every four years, giving an average of 365.25 — overshooting by roughly 11 minutes a year. Across centuries that drift accumulated into days, which is why the Gregorian reform of 1582 added an exception: century years are leap years only if divisible by 400.

So 1600 and 2000 were leap years. 1700, 1800 and 1900 were not. The resulting average is 365.2425 days, accurate to about one day in 3,000 years.

For age calculation this matters in two ways. First, any tool that estimates days by multiplying years by 365.25 will be wrong for anyone whose life spans 1900 or 2100. Counting real calendar days avoids the problem entirely, which is what a well-built calculator does. Second, people born on 29 February have a birthday that exists on the calendar only about once every four years — covered in detail in our guide to leap year birthdays.

Daylight saving and the off-by-one bug

This one is invisible until it isn't. Many calculators represent a date internally as midnight on that day. Subtract two midnights and you get an exact number of days — except twice a year, in regions that observe daylight saving, when one of those days is 23 or 25 hours long.

The subtraction then yields something like 13,247.958 days. Round it and you are fine; truncate it, as integer division does by default, and you get 13,247 instead of 13,248. The age is wrong by a day, and only for part of the year, which makes it maddening to reproduce and easy to ship.

The robust fix is to anchor every calendar date at midday rather than midnight. A one-hour shift then leaves eleven hours of margin on either side and can never cross a day boundary. Our calculators do this throughout, which is why a result checked in March still holds in July.

A related trap affects the web specifically: in JavaScript, new Date("1990-05-12") is parsed as UTC midnight, so for anyone west of Greenwich it represents the evening of 11 May in local time. Every age computed from it is a day short. Date strings have to be parsed component by component, not handed to the default parser.

Which figure should you use?

Match the figure to the decision it is feeding.

• Forms, eligibility and legal thresholds want completed years on a stated date. Set the comparison date to the deadline rather than to today — the two often differ, and it is usually the deadline that governs.
• Educational and clinical assessment wants years and completed months, written as 8;4, computed to the test date. Our chronological age calculator reports it in that form.
• Contracts, interest and notice periods want days. Check whether the period is inclusive of both endpoints, which changes the answer by one.
• Curiosity can have whatever unit is most fun. Seconds are the crowd-pleaser.

If two tools disagree, compare their day counts before anything else. If the day counts match, the difference is purely a month-convention question and neither is wrong. If the day counts differ, one of them has a genuine bug — and it is usually the daylight-saving one.

Frequently asked questions

Try it yourself