A form asks for your date of birth, and behind the scenes, "age" gets calculated by subtracting one date from another. This sounds like it should be one of the simplest possible calculations in software — and yet date arithmetic is a well-known source of subtle, recurring bugs, precisely because human calendars are full of irregularities that a naive subtraction doesn't account for.
Why you can't just subtract years
The most naive approach to calculating age — subtract birth year from current year — is wrong for roughly a quarter of the year for any given person, specifically whenever the current date falls before their birthday in the current calendar year. Someone born in December, calculated in January of the following year using pure year subtraction, would show as one year older than they actually are, because the subtraction doesn't check whether the birthday has actually occurred yet this year.
The correct logic requires comparing not just years but the full month-and-day position: subtract the birth year from the current year, then check whether the current month-and-day combination is before the birth month-and-day combination, and subtract one more year from the result if so. It's a small amount of extra logic, but skipping it is an extremely common off-by-one bug, and one that only manifests for roughly a third of any test dataset depending on which birthdays happen to be included, which is exactly the kind of bug that's easy to miss in casual testing and only surfaces once real user data with a wide spread of birthdays hits the system.
Months have different lengths, and that breaks naive day-counting
Calculating the number of days between two dates by naive subtraction works fine if you're working with a library that properly represents dates as a continuous count of days (most modern date libraries do this correctly under the hood). But any manual calculation that tries to reason about "days in this month" without correctly handling that months range from 28 to 31 days, and that February specifically varies between 28 and 29 depending on leap year status, is a recipe for an off-by-a-few-days bug that only shows up for date ranges spanning specific months.
Leap years aren't just "every four years"
The commonly known leap year rule — a year divisible by 4 is a leap year — is actually incomplete. The full rule has an exception: a year divisible by 100 is not a leap year, unless it's also divisible by 400, in which case it is one after all. This means the year 2000 was a leap year (divisible by 400), but 1900 was not (divisible by 100 but not 400), despite both being divisible by 4. Code that implements only the simple "divisible by 4" rule without the century exceptions will be correct the overwhelming majority of the time, since century-boundary years are rare, but will produce a wrong result specifically on those century-boundary edge cases, which is exactly the kind of bug that can sit undetected in a codebase for decades before a century boundary actually comes around and exposes it.
February 29th creates a genuinely ambiguous birthday
Someone born on February 29th has a birthday that, strictly speaking, only exists once every four years. Any system that needs to determine "has this person's birthday occurred yet this year" for a non-leap year has to make a judgment call about whether to treat February 28th or March 1st as the observed birthday in years when the 29th doesn't exist — there's no universally agreed-upon single correct answer, and different systems handle it differently, which occasionally produces visibly inconsistent results if a person's age is calculated by two different systems that made opposite judgment calls on this specific edge case.
Why relying on a real date library beats hand-rolled logic
Every one of these issues has already been solved correctly, exhaustively tested, and handled consistently inside any mature date-handling library available in virtually every programming language. The recurring pattern behind date bugs in production software is almost always someone reimplementing a piece of this logic by hand — for a task that felt simple enough not to need a full library — rather than an actual limitation in the available tooling. Trusting a well-tested library's date arithmetic over custom date-subtraction logic written for one specific feature is one of the more reliable ways to sidestep this entire category of bug before it happens.
Calculating age or date differences yourself
If you just need a quick, correctly-calculated age or date difference without writing any code, our age calculator and date difference calculator both handle the leap year and month-boundary logic correctly behind the scenes, giving an accurate result without needing to reason through any of the edge cases above yourself.
The underlying lesson
Calendars are a human convention layered with historical irregularities — leap years, varying month lengths, century exceptions — that don't map cleanly onto simple arithmetic. Code that treats dates as if they were plain numbers you can subtract naively will be correct most of the time and subtly wrong at the edges, which is exactly the failure mode that's hardest to catch in testing and most annoying to debug once it's already shipped.