Age Calculator

In every Western legal system, age increments on the anniversary of your birth — the day before your birthday, you are N; the day of, you are N+1. For non-leap-day birthdays this is unambiguous. For leap-day births, jurisdictions differ:

• UK / Hong Kong / New Zealand — you "age" on March 1 in non-leap years.
• Taiwan — you age on February 28 in non-leap years.
• US — varies by state and context (driver's licenses often March 1, contracts often February 28).
• Most software — pick one of the two and document. The choice rarely matters except for the ~0.07% of people born on Feb 29.

Other parts of the world have additional complications. East Asian age (한국식 나이) used to count from 1 at birth and increment every Lunar New Year regardless of birthday — South Korea legally switched to international age in 2023, but cultural use persists in some contexts.

• Birth time recorded in the local time of birth — but if someone moves to a different timezone, "their birthday" in their new local time may shift by a day. Most apps ignore this; if you are computing legal age across borders, anchor to UTC or the birth-location time zone.
• DST transitions never change the date, only the hour. Age in days is unaffected. Age in hours is off by ±1 across each DST event.
• Historical timezone changes — some countries changed timezones (Turkey 2016, North Korea 2015, Russia repeatedly). For people born under the old timezone, library dates may shift. Use IANA tzdb-aware libraries (Luxon, date-fns-tz, java.time) instead of ad-hoc math.

• You are doing paperwork that asks for exact age (or "age at as-of date") and want a single source of truth across years/months/days.
• You are calculating "days until retirement" or "days until a milestone date" and want both inputs and outputs to validate against a calendar.
• You are debugging an age-validation form in your app and need a reference value for known birth dates.
• You are curious about cultural age conventions (Korean age before 2023, Chinese zodiac year cycles) for a specific birthdate.

• It will not predict life expectancy. "How long do I have left" is statistical, depends on geography, gender, lifestyle, and family history. Insurance-grade actuarial tables exist but are out of scope.
• It will not handle non-Gregorian calendars natively. Hebrew, Hijri, Persian, and Chinese lunisolar calendars all have their own rules; conversions exist but are date-library specific.
• It will not validate that the input date is "possible" beyond range checking. Garbage input (year 4000 future date, year 0 past date) is accepted and computed against; the math is correct, the semantics are your problem.