Age looks like the simplest calculation there is: subtract one year from another. It stays simple right up until someone needs an exact figure for a visa form, a pension threshold or a school cut-off date, and then the edge cases arrive all at once.
Why dividing by 365 is wrong
The quickest approach is to count the days between two dates and divide by 365. It is also wrong, and predictably so: it drifts by roughly one day for every four years, because leap years exist.
Over a 40-year span that is about ten days of error. Usually harmless, occasionally not, and always avoidable by counting the calendar properly rather than approximating it.
Months are not a fixed length
The correct method is to count years, then months, then days, borrowing as you go, in the same way you would subtract by hand. Someone born on 15 March 1990, on 10 September 2026, is 36 years, 5 months and 26 days old.
The borrowing step is where implementations disagree. If the day of the month has not yet been reached, you borrow days from the previous month, and the answer depends on which month you borrow from. Borrowing from February gives 28 days; from March, 31. Both are defensible, and different systems genuinely produce different results.
Leap day birthdays
Someone born on 29 February has no birthday in most years, and the law has to decide when they legally turn 18. Different jurisdictions pick 28 February or 1 March, and software follows suit inconsistently.
If a date near the end of February matters legally, check the rule that applies where you are rather than trusting any calculator.
Why "age in months" is ambiguous
Ask how many months old a baby is and there are several valid answers: completed calendar months, total days divided by 30, or days divided by 30.44, the average month length. A paediatric chart, a visa form and an insurance table may each expect a different one.
This is why a good calculator shows several views at once: years, months and days together, plus total weeks and total days. Different forms want different units, and converting between them by hand is exactly where mistakes creep in.
Time zones and the date itself
Age is normally computed in local calendar dates, but a birth recorded at 23:40 in one time zone may be the following date elsewhere. For anything official, use the date written on the document rather than a timestamp.
What to check in any result
- Does the day count look right against a calendar for a short span you can verify by hand?
- Does it handle a birthday that has not yet occurred this year, rather than assuming it has?
- Does it give you total days as well as years and months, so you can cross-check?
- Does it cope with dates before 1970, which some implementations handle badly?