Why Most Age Calculators Get Leap Years Wrong (and How to Check Yours)

Date math looks simple until you actually try to implement it. "How old is someone" seems like basic subtraction, but the moment you involve real calendars — months of different lengths, leap years, and the once-every-four-years oddity of February 29 — a naive implementation breaks in ways that are easy to miss during casual testing and embarrassing when a user actually hits them.

The Feb 29 problem

Someone born on February 29 has a birthday that, strictly speaking, only exists once every four years (with the additional century-year exception: years divisible by 100 are not leap years unless also divisible by 400 — so 2000 was a leap year, but 1900 and 2100 are not). In the other three years out of four, there's no literal February 29 on the calendar. So when does that person's birthday "happen" in a non-leap year? There's no single universally agreed answer, but the common convention — and the one that matches how most government and legal systems informally treat it — is to observe it on February 28. A calculator that doesn't explicitly handle this case will either throw an error, silently produce a wrong date, or in the worst case crash entirely when asked to compute "years since Feb 29, 2000" as of a non-leap-year date.

The month-length trap

A second, subtler bug shows up in month/day arithmetic. Consider calculating the difference between January 31 and March 1 of the same year. Naive algorithms that try to "borrow" days from the previous calendar month when the day-of-month subtraction goes negative can end up borrowing from February — which only has 28 or 29 days — and produce a negative remainder when the original day (31) doesn't fit within what's available to borrow. This is a genuinely common bug in hand-rolled date-difference code, and it's the kind of thing that only surfaces on specific date combinations, meaning it can sit undetected in production for a long time.

Multi-leap-year spans

A third case worth checking: does the calculator correctly compute a difference like January 1, 2016 to January 1, 2024 — a span crossing three separate leap years (2016, 2020, 2024)? The total day count needs to correctly include the extra days from each leap year, or you'll be off by up to three days on an eight-year span. This one is easier to get right than the previous two, but it's still worth explicitly verifying rather than assuming.

How to sanity-check any age or date-difference tool

1. Enter a birth date of February 29 on a leap year, and check the calculated age as of a date in a non-leap year — it should produce a sensible result, not an error or an obviously wrong number.
2. Check the same Feb 29 birth date's "days until next birthday" countdown on both sides of February 28/March 1 in a non-leap year, to confirm the birthday is being observed consistently.
3. Compute the difference between two dates with different month lengths — January 31 to March 1 is a good stress test — and confirm the days component doesn't go negative.
4. Compute a difference spanning at least one full leap year and confirm the total day count matches manual calculation.

What a correct implementation looks like

The most robust approach avoids the "borrow days from the previous month" trap entirely: instead of subtracting day-of-month values directly, it advances the earlier date by whole years, then by whole months (using a calendar that clamps to the last valid day of a shorter target month), and only then measures the small remaining gap in literal days. This sidesteps the negative-remainder bug by construction, rather than patching around it case by case.

Why this matters beyond curiosity

Age and date-difference calculations show up in contexts where being off by even one day matters: eligibility checks, contract terms, insurance calculations, and legal age verification. A calculator that silently mishandles Feb 29 or crosses a leap year incorrectly isn't just a minor inconvenience — it's producing a wrong answer with confidence, which is worse than producing no answer at all.