Ask someone their age and they'll answer instantly. Ask a computer and it has to navigate leap years, months of uneven length, and the occasional leap second. Date arithmetic looks simple until you try to pin down the exact rules — which is why dedicated calculators exist, and why getting the logic right matters for everything from legal age checks to project deadlines.
This guide explains how age and date calculations actually work under the hood: the calendar rules involved, how to work through examples by hand, and the edge cases that trip up both people and software.
How age is really calculated
Age in years isn't simply "current year minus birth year" — that shortcut is only correct for part of the year. The real rule: you turn a year older on the anniversary of your birth date.
Take a concrete example: someone born 20 June 1990, and today is 15 October 2026.
- Subtract the years: 2026 − 1990 = 36.
- Check whether the birthday has occurred yet this year: 20 June has passed (it's October), so no adjustment.
- Age = 36 years.
Now the same person on 19 June 2026 (day before the birthday): 2026 − 1990 = 36, but the birthday hasn't occurred yet, so subtract one → 35 years. That "has the anniversary passed?" check is the entire subtlety of year calculation — and the step naive implementations forget.
For a full breakdown (years, months, days), calculators borrow like subtraction with carrying: if today's day-of-month is smaller than the birth day, borrow the previous month's length and subtract a month; if the month is then smaller, borrow 12 months and subtract a year. Example — born 25 March 1990, today 15 October 2026: days 15 < 25, so borrow September's 30 days → 45 − 25 = 20 days; months 9 − 3 = 6; years 2026 − 1990 = 36. Result: 36 years, 6 months, 20 days. An age calculator does this instantly.
Leap years: the actual rule
A year isn't exactly 365 days — it's about 365.2422. Without correction, the calendar would drift about 6 hours a year. The Gregorian calendar fixes this with leap years, and the rule has three parts:
- Divisible by 4 → leap year (2024, 2028).
- Except years divisible by 100 → not leap years (1900, 2100).
- Except years divisible by 400 → leap years after all (2000, 2400).
So 2000 was a leap year, 1900 was not, and 2100 will not be. This three-tier rule keeps the calendar aligned to within a day over thousands of years.
Why it matters for calculations: anyone doing date arithmetic across February must know whether that February had 28 or 29 days. A "one year later" calculation from 29 February needs a decision rule too — most systems (and most legal conventions) treat 28 February as the anniversary in non-leap years, though some use 1 March. If exactness matters — contracts, eligibility cut-offs — check which convention applies rather than assuming.
Month lengths: the uneven dozen
Months are the irregular heart of date math: 28/29, 30, or 31 days, with no pattern except the knuckle mnemonic. This irregularity is why "add one month" is ambiguous — one month after 31 January is... 28 (or 29) February? 3 March? Different software answers differently:
- Clamp to month end: 31 Jan + 1 month = 28 Feb (last valid day).
- Overflow: 31 Jan + 1 month = 2 or 3 Mar (the excess days spill over).
Neither is "wrong" — but mixing them in one system causes bugs. When you see a date calculator, it has picked one convention; for critical dates (billing cycles, subscription renewals), verify which one rather than discovering it from an angry customer.
Counting days between two dates
"How many days between 10 October and 25 December?" seems trivial until you decide whether to count the endpoints. The standard convention in computing: date difference = end date minus start date, exclusive of the start, inclusive of the end — i.e., 25 Dec minus 10 Oct counts the days 11 Oct through 25 Dec.
Worked example — days from 10 October 2026 to 25 December 2026:
- October: 31 − 10 = 21 days remaining (11–31 Oct)
- November: 30 days
- December: 25 days (1–25 Dec)
- Total: 21 + 30 + 25 = 76 days
The classic off-by-one error is counting both endpoints (getting 77) or neither (75). For project planning it rarely matters; for interest calculations, SLA deadlines, and legal notice periods, one day absolutely matters — always confirm whether the count is inclusive or exclusive.
Time zones and daylight saving: the hidden traps
Once times enter the picture, two more complications appear. Time zones mean "15 October" starts at different absolute moments around the world — any deadline or timestamp must pin down whose midnight. And daylight saving transitions make some days 23 or 25 hours long, so adding 86,400 seconds isn't always "one day later." Robust systems add calendar days, not seconds — which is why professional date libraries exist, and why hand-rolled date code is a notorious source of bugs.
Common mistakes
- Year subtraction without the birthday check — the #1 age-calculation error.
- Assuming February always has 28 days in multi-year spans.
- Treating "a month" as 30 days — fine for rough estimates, wrong for exact dates (a "30-day month" assumption drifts by up to 3 days per month).
- Off-by-one day counts from unclear inclusive/exclusive conventions.
- Forgetting the century rule — 2100 is not a leap year, and long-range planners occasionally get this wrong.
- Leap-day birthdays: someone born 29 February 2000 turned 6 (in leap-year count) in 2024 but 24 in years lived. Define which you mean before calculating.
Frequently asked questions
How old am I exactly, in years, months, and days?
Use the borrow method described above, or simpler — an age calculator that implements it. You'll need your full birth date and today's date; the calculator handles leap years and uneven months automatically.
Is 2000 a leap year? Is 2100?
2000 was a leap year (divisible by 400). 2100 will not be (divisible by 100 but not 400). The full rule — divisible by 4, except centuries, except centuries divisible by 400 — is the one to memorise.
Why do some calculators give a different day count than others?
Almost always the inclusive/exclusive endpoint convention, or a different "add a month" rule. A one-day difference between tools is normal and just reflects different (both defensible) conventions — check which one your use case requires.