When Age Calculations. Get Weird.

Months don't have a fixed length

"1 month later" is ambiguous. Jan 31 + 1 month is... Feb 28? (last day of next month). Feb 31? (doesn't exist). March 3? (31 calendar days later). Every date library chooses a rule; they don't all choose the same one.

Common approaches:

• "Clamp" to last valid day — Jan 31 + 1 month = Feb 28 (or Feb 29 in leap years). Most common.
• Overflow to next month — Jan 31 + 1 month = Feb 31 → March 3. PHP's default behavior.
• Error on ambiguity — some strict libraries reject the operation.

Leap years and Feb 29

A person born Feb 29, 2020: on Feb 28, 2021, are they 1 year old? On March 1, 2021? Depends on jurisdiction (most say March 1). Our age calculator uses March 1. Different libraries pick different rules; be explicit about which you're using.

Timezones at the boundary

Born at 11:30 PM Eastern on March 3. Moved to Tokyo. Now your passport says March 3; the Japanese calendar says March 4 UTC. Age calculators typically treat the "birth date" as whatever was local at the time of birth — not a UTC timestamp. This means "age" is a date difference, not a timestamp difference.

The "when do you increment" ambiguity

Most calculators increment age at midnight of the birthday. Some increment at 23:59:59 the day before. The difference is one day, which rarely matters — unless you're computing eligibility for something time-sensitive (voting age, drinking age, retirement benefits). Legal systems typically use "attained" age, which increments at start of birthday.

Total-unit counts (hours, minutes) vs calendar units (years, months)

Total hours since birth is unambiguous — one number, any timezone. Total calendar years + months + days is path-dependent. Most calculators output both; use total-unit counts when you need exactness, calendar units when you want "30 years, 2 months, 4 days old".