How "Age" Is Actually Calculated (and Where the Off-by-One Bugs Hide)

"How old are you" seems like subtraction. It's actually date arithmetic with a borrowing rule, and almost every hand-rolled age calculator gets at least one edge case wrong.

The naive version, and why it's wrong

The obvious approach: age = currentYear - birthYear. This is wrong for anyone whose birthday hasn't happened yet this year — someone born June 2010 is still 15 in March 2026, not 16, even though 2026 − 2010 = 16.

The fix everyone reaches for next: subtract one if the current month/day is before the birth month/day. That handles years correctly, but a full "years, months, and days" breakdown needs the same borrowing logic one level down.

Borrowing days from months

To compute the months and days portion of an age (not just years), you subtract the birth date's month-day from today's month-day the same way you'd subtract 47 − 8 in a lower place value than you have — except a "month" isn't a fixed number of days, so how much you borrow depends on which month you're borrowing from.

Concretely: if today is March 5 and the birthday is January 20, you can't do "5 − 20" directly. You borrow a month, which means going back one full month (February, in this case) and adding its day count (28 or 29) to the 5, then subtracting: (5 + 28) − 20 = 13 days, and the month count drops by one. Get the borrowed month's day count wrong — using 30 as a generic placeholder instead of checking the actual month — and every age calculation involving a January or February birthday is quietly off by one or two days.

Leap years compound the problem

If the day you're borrowing is February, whether it has 28 or 29 days depends on the leap year rule: divisible by 4, except centuries, unless divisible by 400. (2000 was a leap year; 1900 wasn't; 2024 was.) A calculator that hardcodes February as 28 days will be off by exactly one day for anyone whose age calculation borrows across a leap February — a bug that only appears one year in four, which is exactly why it's easy to ship without noticing.

Time zones: the silent corrupter

If an age calculator uses new Date() and compares it against a stored birth date without normalizing both to the same reference, a user in a timezone ahead of UTC can see their age tick over a day early (or late) around midnight, because "today" briefly disagrees between the browser's local clock and however the birth date was stored. The fix is to do all the date math in a single fixed reference frame (UTC) and never let the calculation depend on the viewer's local clock.

Korea's separate age system

Korean age (만 나이) isn't a units difference — it's a different calculation from the "international age" most calculators assume. Until a 2023 legal standardization, Korea commonly used counting age, where everyone is born at age 1 and gains a year on January 1st (not on their birthday) — meaning a baby born December 31st turns "2" the very next day. A generic age calculator applying the international years/months/days formula to a Korean-age question will produce a plausible-looking but wrong number, because it's answering a different question than the one asked.

Why it's worth using a dedicated tool

Getting all of this right — borrow logic, leap years, timezone-safe comparisons, and knowing which age system actually applies — is exactly the kind of thing worth not re-deriving by hand. Spellkit's Age Calculator handles the international system (years/months/days, totals, and next-birthday countdown), and the separate Korean Age tool handles 만 나이 specifically, since the two aren't interchangeable.