How Age Calculators Work: The Logic of Leap Years

Category: Utils

Quick Answer (for Featured Snippets)

• An age calculator compares two instants (birth and now), then returns calendar-aware parts (years, months, days) and optional totals (days, hours, minutes, seconds).
• Accurate tools follow Gregorian leap-year rules (every 4 years, except centuries unless divisible by 400), handle Feb 29 birthdays, account for variable month lengths, and compute with time zones correctly.
• Best practice: compute totals from UTC instants; compute years/months/days using calendar math in the user’s time zone; document Feb 29 and inclusivity policies.

Key Takeaways

• Leap years follow a 4/100/400 rule that changes the length of February and total days lived.
• "Age" in years/months/days is calendar math, not just dividing by fixed day counts.
• Feb 29 birthdays require a clear policy in non-leap years (Feb 28 vs Mar 1) and must be applied consistently.
• Normalizing to UTC avoids DST and time-zone off-by-one errors; display results in the user’s IANA time zone.
• A reliable algorithm adds whole years, then months, then days, without overshooting the target instant.
• Always state whether day counts are inclusive or exclusive of the birth date.

---

Table of Contents

• Why an Age Calculator Is Harder Than It Looks
• The Gregorian Leap-Year Rules (Explained Clearly)
• Handling Feb 29 Birthdays (Policy Options)
• Month Length Variation and End-of-Month Logic
• Time Zones, UTC, and Daylight Saving Time (DST)
• A Production-Grade Algorithm (Step by Step)
• Reference Implementations (JavaScript, Python, Java)
• Worked Examples (With Expected Results)
• Testing & QA Checklist
• Common Pitfalls and How to Avoid Them
• Legal, Product, and Localization Considerations
• Performance, Reliability, and Observability
• Accessibility & UX Tips for Age Tools
• FAQs
• Try It with ZenixTools
• References & Further Reading
• About This Guide

---

Why an Age Calculator Is Harder Than It Looks

Age calculators seem trivial—just subtract one date from another. In practice, building a trustworthy tool requires you to:

• Implement exact Gregorian leap-year logic.
• Decide how to treat Feb 29 birthdays in non-leap years.
• Handle months of different lengths (28–31 days).
• Avoid time-zone and DST traps that shift dates by a day.
• Be explicit about inclusive vs exclusive day counts.
• Return both human-friendly parts (years, months, days) and precise totals (days, hours, seconds) when needed.

This guide explains the reasoning, shows robust algorithms, and provides production-ready examples you can copy and adapt.

---

The Gregorian Leap-Year Rules (Explained Clearly)

Leap years affect the length of February and total day counts. The Gregorian calendar rule set is:

• A year is a leap year if it is divisible by 4.
• Exception: If the year is divisible by 100, it is not a leap year.
• Exception to the exception: If the year is divisible by 400, it is a leap year.

Examples:

• 2000 → leap (divisible by 400)
• 1900 → not leap (divisible by 100 but not 400)
• 1996, 2024 → leap (divisible by 4, not 100)
• 2100 → not leap (divisible by 100, not 400)

Why it matters:

• February has 29 days in leap years; 28 otherwise.
• Total days lived differs notably for date ranges that cross leap years.
• Calendar math for “years” and “months” must respect where leap days fall.

Note on historical dates:

• Most software uses the proleptic Gregorian calendar for historical computations (applying Gregorian rules backward). If you need historical accuracy around 1582 or regional adoption differences, document that scope clearly.

---

Handling Feb 29 Birthdays (Policy Options)

People born on February 29 have a birthday only in leap years. In non-leap years, you must choose a policy. There is no single universal rule; locale, legal, and product requirements vary.

Common policies:

• Feb 28 policy: Celebrate/compute the anniversary on February 28 in non-leap years. Simple and commonly expected in some contexts.
• Mar 1 policy: Use March 1, aligning with “the day after Feb 28.” This also appears in some legal contexts.
• Configurable policy: Let users or regions choose their preference. This is best for global apps.

Implementation tips:

• Apply the policy only to yearly anniversaries. When returning totals or counting actual days, always use actual elapsed time.
• Document your policy in product help text or a tooltip near the input.
• If your product deals with legal ages (e.g., majority, drinking, voting), consult a legal team because jurisdictions may specify which date to use in non-leap years.

---

Month Length Variation and End-of-Month Logic

Months are not equal. A robust algorithm reflects how humans interpret anniversaries and durations.

Recommended approach:

• Compute years → then months → then days, without overshooting the target instant.
• If the birth day is near the end of a long month, clamp to the last valid day of the target month (e.g., Jan 31 + 1 month = Feb 28 or Feb 29 in leap years, then Mar 31 for the next month).
• Never treat “a month” as a fixed number of days (like 30). That leads to user-visible inaccuracies.

This approach matches the intuitive idea of anniversaries and ensures “1 month” means “one calendar month later,” not “30 days later.”

---

Time Zones, UTC, and Daylight Saving Time (DST)

Age calculations cross boundaries where calendar dates can change unexpectedly.

Best practices:

• Use UTC to compute raw elapsed time (seconds, minutes, hours, total days). This avoids DST and time-zone ambiguities.
• Convert to the user’s display time zone (IANA format such as America/New_York) when computing calendar parts (years, months, days) and when presenting results.
• Always parse inputs with time zone awareness. Treating a local time as “floating” can yield off-by-one-day results near midnight boundaries.
• Be careful around DST:
  • Spring forward: some local times do not exist (skipped hour).
  • Fall back: some local times repeat (ambiguous hour). Use library functions that resolve ambiguities consistently.
• Cross-time-zone scenarios:
  • The same instant can map to different calendar dates in different zones. Computing totals in UTC ensures consistent numerical results, while calendar parts reflect the chosen display zone.

---

A Production-Grade Algorithm (Step by Step)

1. Parse inputs with explicit time zones

• Capture birth date, time, and IANA time zone. If the original birth time zone is unknown, use the user’s display zone and state that assumption in the UI.

2. Normalize to UTC for totals

• Convert birth and “now” instants to UTC.
• Compute totalSeconds, totalMinutes, totalHours, totalDays from the UTC difference. Document whether totalDays is exclusive or inclusive.

3. Calendar-aware parts in the display zone

• Convert both instants to local dates in the display zone.
• Build a cursor starting at the birth local date/time. Add whole years until adding one more would exceed “now.”
• Add whole months with the same rule. Clamp end-of-month dates when needed.
• Finally, add days, then (optionally) hours, minutes, seconds.

4. Feb 29 policy

• If birth is Feb 29 and the current year is not leap, apply the configured policy (Feb 28 or Mar 1) when considering anniversaries.

5. Inclusivity policy

• Decide whether to count the birth day in totals. Many tools present totalDays as exclusive of the birth day. Whatever you choose, document it.

6. Return structured output

• Return calendar parts (years, months, days) plus totals (days, hours, minutes, seconds). Include the time zone used and the policies applied for transparency.

7. Validate and test

• Run the test suite described below, including leap years, end-of-month cases, and DST transitions.

---

Reference Implementations (Copy & Adapt)

Leap-Year Check (Shared)

function isLeapGregorian(year) {
  return (year % 4 === 0) && (year % 100 !== 0 || year % 400 === 0);
}

JavaScript (Temporal API)

The Temporal API is broadly available in modern runtimes. If you target older environments, use a polyfill or a robust date library that supports IANA zones.

// Age calculation with UTC totals and calendar-aware parts using Temporal.
// Policies: feb29Policy = 'feb28' | 'mar1'
// inclusivity: 'exclusive' (default) | 'inclusive'

function calculateAge({
  birthISO,           // e.g., '2000-02-29T08:15:00'
  birthTimeZone,      // e.g., 'America/New_York'
  displayTimeZone,    // e.g., 'America/New_York' (user’s zone)
  nowZoned,           // optional Temporal.ZonedDateTime; defaults to now in display zone
  feb29Policy = 'feb28',
  dayCountInclusivity = 'exclusive'
}) {
  const tzDisplay = displayTimeZone || birthTimeZone;

  // Build ZonedDateTime for birth in its original zone
  const birthZdt = Temporal.ZonedDateTime.from({
    timeZone: birthTimeZone,
    ...Temporal.PlainDateTime.from(birthISO).getISOFields()
  });

  // Determine "now" in display zone
  const now = nowZoned || Temporal.Now.zonedDateTimeISO(tzDisplay);

  // 1) Totals via UTC instants
  const birthInstant = birthZdt.toInstant();
  const nowInstant = now.toInstant();
  let seconds = nowInstant.epochSeconds - birthInstant.epochSeconds;
  let minutes = Math.floor(seconds / 60);
  let hours = Math.floor(minutes / 60);
  let totalDays = Math.floor(hours / 24); // exclusive by default
  if (dayCountInclusivity === 'inclusive') totalDays += 1;

  // 2) Calendar-aware parts in display zone
  // Represent both instants in the display zone for human-readable parts
  const birthInDisplay = birthZdt.withTimeZone(tzDisplay);
  const nowInDisplay = now.withTimeZone(tzDisplay);

  // Start cursor at birth in display zone
  let cursor = birthInDisplay;
  let years = 0, months = 0, days = 0;

  // Add whole years without overshoot
  while (cursor.add({ years: 1 }) <= nowInDisplay) {
    cursor = cursor.add({ years: 1 });
    years++;
  }

  // Feb 29 policy on non-leap target years when anniversary alignment matters
  if (birthInDisplay.month === 2 && birthInDisplay.day === 29 && !isLeapGregorian(cursor.year)) {
    if (feb29Policy === 'mar1') cursor = cursor.with({ month: 3, day: 1 });
    else cursor = cursor.with({ month: 2, day: 28 });
    if (cursor > nowInDisplay) {
      years--; // adjust if the policy-based date overshoots
      // Rebuild cursor at new anniversary in previous year
      const adjYear = birthInDisplay.year + years;
      const target = feb29Policy === 'mar1' ? { month: 3, day: 1 } : { month: 2, day: 28 };
      cursor = cursor.with({ year: adjYear, month: target.month, day: target.day });
    }
  }

  // Add whole months without overshoot
  while (cursor.add({ months: 1 }) <= nowInDisplay) {
    cursor = cursor.add({ months: 1 });
    months++;
  }

  // Add days without overshoot
  while (cursor.add({ days: 1 }) <= nowInDisplay) {
    cursor = cursor.add({ days: 1 });
    days++;
  }

  return {
    parts: { years, months, days },
    totals: { totalDays, totalHours: hours, totalMinutes: minutes, totalSeconds: seconds },
    meta: {
      displayTimeZone: tzDisplay,
      birthTimeZone,
      feb29Policy,
      dayCountInclusivity
    }
  };
}

Python (datetime + zoneinfo)

from datetime import datetime, timezone, timedelta
from zoneinfo import ZoneInfo

def is_leap_gregorian(year: int) -> bool:
    return (year % 4 == 0) and (year % 100 != 0 or year % 400 == 0)

def calculate_age(
    birth_iso: str,              # '2000-02-29T08:15:00'
    birth_tz: str,               # 'America/New_York'
    display_tz: str | None = None,
    now_utc: datetime | None = None,
    feb29_policy: str = 'feb28', # or 'mar1'
    day_count_inclusivity: str = 'exclusive'
):
    display_tz = display_tz or birth_tz

    # Parse birth in birth time zone
    birth_local = datetime.fromisoformat(birth_iso).replace(tzinfo=ZoneInfo(birth_tz))

    # Now in display zone
    now_local = (now_utc or datetime.now(timezone.utc)).astimezone(ZoneInfo(display_tz))

    # 1) Totals via UTC instants
    birth_utc = birth_local.astimezone(timezone.utc)
    now_utc_inst = now_local.astimezone(timezone.utc)
    delta = now_utc_inst - birth_utc
    total_seconds = int(delta.total_seconds())
    total_minutes = total_seconds // 60
    total_hours = total_minutes // 60
    total_days = total_hours // 24
    if day_count_inclusivity == 'inclusive':
        total_days += 1

    # 2) Calendar-aware parts in display zone
    # Build a cursor at birth in display zone
    birth_disp = birth_local.astimezone(ZoneInfo(display_tz))
    cursor = birth_disp
    years = months = days = 0

    def add_years(d: datetime, n: int) -> datetime:
        try:
            return d.replace(year=d.year + n)
        except ValueError:
            # Handle Feb 29 -> Feb 28/29 as needed for validity
            # We defer policy-specific anniversary handling below;
            # here we clamp to last valid day for general stepping
            return d.replace(month=2, day=28, year=d.year + n)

    def add_months(d: datetime, n: int) -> datetime:
        y = d.year + (d.month - 1 + n) // 12
        m = (d.month - 1 + n) % 12 + 1
        # Clamp day to last valid day of target month
        for day in [d.day, 30, 29, 28, 27]:
            try:
                return d.replace(year=y, month=m, day=day)
            except ValueError:
                continue
        # Fallback
        return d.replace(year=y, month=m, day=28)

    # Add whole years without overshoot
    while add_years(cursor, 1) <= now_local:
        cursor = add_years(cursor, 1)
        years += 1

    # Apply Feb 29 policy for anniversary alignment
    if birth_disp.month == 2 and birth_disp.day == 29 and not is_leap_gregorian(cursor.year):
        if feb29_policy == 'mar1':
            policy_date = cursor.replace(month=3, day=1)
        else:
            policy_date = cursor.replace(month=2, day=28)
        if policy_date > now_local:
            years -= 1
            adj_year = birth_disp.year + years
            if feb29_policy == 'mar1':
                cursor = cursor.replace(year=adj_year, month=3, day=1)
            else:
                cursor = cursor.replace(year=adj_year, month=2, day=28)
        else:
            cursor = policy_date

    # Add whole months without overshoot
    while add_months(cursor, 1) <= now_local:
        cursor = add_months(cursor, 1)
        months += 1

    # Add days without overshoot
    while cursor + timedelta(days=1) <= now_local:
        cursor = cursor + timedelta(days=1)
        days += 1

    return {
        'parts': {'years': years, 'months': months, 'days': days},
        'totals': {
            'totalDays': total_days,
            'totalHours': total_hours,
            'totalMinutes': total_minutes,
            'totalSeconds': total_seconds
        },
        'meta': {
            'displayTimeZone': display_tz,
            'birthTimeZone': birth_tz,
            'feb29Policy': feb29_policy,
            'dayCountInclusivity': day_count_inclusivity
        }
    }

Java (java.time)

import java.time.*;
import java.time.temporal.ChronoUnit;

public class AgeCalculator {
    public static boolean isLeapGregorian(int year) {
        return (year % 4 == 0) && (year % 100 != 0 || year % 400 == 0);
    }

    public static class Result {
        public final int years, months, days;
        public final long totalDays, totalHours, totalMinutes, totalSeconds;
        public final String displayZone, birthZone, feb29Policy, dayCountInclusivity;
        public Result(int y, int m, int d, long td, long th, long tm, long ts,
                      String dz, String bz, String p, String inc) {
            years = y; months = m; days = d;
            totalDays = td; totalHours = th; totalMinutes = tm; totalSeconds = ts;
            displayZone = dz; birthZone = bz; feb29Policy = p; dayCountInclusivity = inc;
        }
    }

    public static Result calculate(
        String birthIso,           // e.g. 2000-02-29T08:15:00
        String birthZoneId,        // e.g. America/New_York
        String displayZoneId,      // e.g. America/New_York
        Instant nowInstant,        // optional; Instant.now() if null
        String feb29Policy,        // "feb28" or "mar1"
        String dayCountInclusivity // "exclusive" or "inclusive"
    ) {
        ZoneId birthZone = ZoneId.of(birthZoneId);
        ZoneId displayZone = displayZoneId != null ? ZoneId.of(displayZoneId) : birthZone;
        LocalDateTime birthLdt = LocalDateTime.parse(birthIso);
        ZonedDateTime birthZdt = birthLdt.atZone(birthZone);

        Instant now = nowInstant != null ? nowInstant : Instant.now();
        ZonedDateTime nowDisp = now.atZone(displayZone);

        // Totals via UTC instants
        long totalSeconds = ChronoUnit.SECONDS.between(birthZdt.toInstant(), now);
        long totalMinutes = totalSeconds / 60;
        long totalHours = totalMinutes / 60;
        long totalDays = totalHours / 24;
        if ("inclusive".equals(dayCountInclusivity)) totalDays += 1;

        // Calendar-aware parts in display zone
        ZonedDateTime birthDisp = birthZdt.withZoneSameInstant(displayZone);
        ZonedDateTime cursor = birthDisp;
        int years = 0, months = 0, days = 0;

        while (cursor.plusYears(1).compareTo(nowDisp) <= 0) {
            cursor = cursor.plusYears(1);
            years++;
        }

        if (cursor.getMonthValue() == 2 && cursor.getDayOfMonth() == 29 && !isLeapGregorian(cursor.getYear())) {
            ZonedDateTime policyDate = "mar1".equals(feb29Policy)
                ? cursor.withMonth(3).withDayOfMonth(1)
                : cursor.withMonth(2).withDayOfMonth(28);
            if (policyDate.isAfter(nowDisp)) {
                years--;
                int adjYear = birthDisp.getYear() + years;
                cursor = "mar1".equals(feb29Policy)
                    ? cursor.withYear(adjYear).withMonth(3).withDayOfMonth(1)
                    : cursor.withYear(adjYear).withMonth(2).withDayOfMonth(28);
            } else {
                cursor = policyDate;
            }
        }

        while (cursor.plusMonths(1).compareTo(nowDisp) <= 0) {
            cursor = cursor.plusMonths(1);
            months++;
        }
        while (cursor.plusDays(1).compareTo(nowDisp) <= 0) {
            cursor = cursor.plusDays(1);
            days++;
        }

        return new Result(years, months, days, totalDays, totalHours, totalMinutes, totalSeconds,
                          displayZone.getId(), birthZone.getId(), feb29Policy, dayCountInclusivity);
    }
}

---

Worked Examples (With Expected Results)

• Feb 29, 2000 at 10:00 (birth zone: Europe/London) → Feb 28, 2023 at 09:59 (display zone: Europe/London)

  • With Feb 28 policy: age turns 23 on Feb 28, 2023 at 10:00 local. Before that minute, years=22.
  • Totals: computed strictly from UTC instants; leap days are naturally included.

• Jan 31, 2024 → Feb 29, 2024 (display zone: UTC)

  • Years=0, Months=0, Days=29. If you add 1 month to Jan 31, clamp to Feb 29 (leap year). Next monthly step lands on Mar 31.

• Born in New York, 1990-06-15 23:30 EDT → Checking in Tokyo, 2025-06-16 12:15 JST

  • UTC normalization ensures consistent totals regardless of where you check. Calendar parts computed in the chosen display zone (Tokyo) reflect the local date difference.

• DST spring-forward case (America/Los_Angeles): Born 2010-03-14 01:30 PST → 2026-03-14 01:25 PDT

  • The 02:00 hour is skipped the day you were born. Accurate libraries handle this; age turns at the instant corresponding to 01:30 PST in UTC.

• Inclusive vs exclusive days: Birth 2020-01-01 00:00 UTC → 2020-01-02 00:00 UTC

  • Exclusive totalDays=1; Inclusive totalDays=2. Pick one and document it.

---

Testing & QA Checklist

• Leap years
  • Years divisible by 4 (e.g., 1996, 2024)
  • Century years (1900 not leap, 2000 leap)
  • Future centuries (2100 not leap, 2400 leap)
• Feb 29 policies
  • Validate both Feb 28 and Mar 1 policy outcomes for multiple target years
  • Ensure policy affects only anniversaries, not raw totals
• End-of-month clamping
  • Jan 31 → Feb (28 or 29), Apr 30 → May 30, etc.
• DST transitions
  • Spring forward and fall back in at least three zones (e.g., America/New_York, Europe/Berlin, Australia/Sydney)
• Time-zone edges
  • Birth in UTC-10, check in UTC+14; verify no off-by-one day errors
• Inclusivity
  • Confirm totalDays choice matches documentation and UI text
• Cross-checks
  • Compare sample outputs against a trusted reference (e.g., ZenixTools) and one other independent calculator
• Property-based tests
  • Randomized round-trips: birth + computed parts → should never overshoot target instant

---

Common Pitfalls and How to Avoid Them

• Treating a month as 30 days
  • Fix: Use calendar math; clamp days for shorter months.
• Ignoring time zones
  • Fix: Parse inputs with IANA zones; compute totals in UTC.
• Mishandling Feb 29
  • Fix: Choose and document a policy; test both options.
• Off-by-one day around midnight
  • Fix: Normalize to UTC instants for totals; compute parts in display zone.
• Assuming local time is unique
  • Fix: Be aware of DST’s repeated or missing hours; rely on library defaults or specify resolution rules.
• Not documenting inclusivity
  • Fix: State clearly whether totals include the birth day.

---

Legal, Product, and Localization Considerations

• Legal age thresholds
  • Some jurisdictions define when an age is attained differently for Feb 29 births or by local date/time. Consult legal counsel for age-restricted features.
• Locale preferences
  • Date formats (DD/MM/YYYY vs MM/DD/YYYY), week starts, and default Feb 29 policies may vary. Offer user-selectable settings.
• Calendar scope
  • If your product supports non-Gregorian calendars, you need separate logic per system. This guide assumes Gregorian.
• Transparency
  • Show the time zone used and the applied policies in an “About this result” or info icon to build trust.

---

Performance, Reliability, and Observability

• Performance
  • Age computations are light. Even millions of evaluations per minute are feasible, but avoid repeated time-zone lookups by caching ZoneId/ZoneInfo objects.
• Reliability
  • Pin your time-zone database version (IANA tzdata). Schedule updates when regions change rules.
• Observability
  • Log inputs (with user consent), time zones, policies used, and output. Add counters for policy branches (e.g., Feb 29 handling) to spot edge-case regressions.

---

Accessibility & UX Tips for Age Tools

• Inputs
  • Use clear placeholders and examples; accept multiple date formats when safe.
• Policies surfaced
  • Let users choose Feb 29 policy with a short explanation. Default to a sensible choice and remember preferences.
• Time zone clarity
  • Auto-detect a display time zone but allow override. Show which zone is applied.
• Explain totals vs parts
  • A short tooltip can clarify that “total days” is computed from UTC instants and may differ from calendar days.
• Validation
  • Prevent impossible dates and provide actionable error messages.

---

FAQs

Why does my age differ by a day on different sites?

Because tools make different choices about time zones, DST, and inclusive vs exclusive day counts. Using UTC for totals and documenting your policy removes ambiguity.

How should we handle Feb 29 birthdays?

Pick a policy—Feb 28 or Mar 1—and apply it consistently. For global audiences, let users choose and explain the implications.

Is a month a fixed number of days?

No. A calendar month can be 28–31 days. Treat months as calendar units, not as 30-day blocks.

Do time zones matter if I only need years and months?

Yes. The local calendar date at the “now” instant depends on the time zone. Compute calendar parts in the user’s IANA time zone.

What’s the most accurate simple method?

• Normalize to UTC for totals.
• Compute calendar-aware parts in the display zone.
• Define Feb 29 and inclusivity policies.
• Use a robust, time-zone-aware library.

Should I count the birth day in total days?

It’s a product decision. Many tools use exclusive counting for totals. Whatever you choose, disclose it and test edge cases.

Can I use epoch days to compute years directly?

No. Years and months are calendar constructs. Compute them by adding whole years and months without overshoot, then days.

Does DST change my birthday time?

Your birthday occurs at the exact instant each year that corresponds to your original birth instant in the local zone. DST may shift the clock time, but a correct algorithm still lands on the right local instant.

---

Try It with ZenixTools

Want instant, accurate results that handle leap years, Feb 29 policies, and time zones correctly? Use the age tools at https://www.zenixtools.com. They follow the best practices in this guide and make edge cases painless.

---

References & Further Reading

• IANA Time Zone Database: https://www.iana.org/time-zones
• ISO 8601 date/time format: https://www.iso.org/iso-8601-date-and-time-format.html
• Temporal API (TC39): https://tc39.es/proposal-temporal/
• Java Time (java.time) Guide: https://docs.oracle.com/javase/8/docs/api/java/time/package-summary.html
• Python datetime and zoneinfo: https://docs.python.org/3/library/datetime.html and https://docs.python.org/3/library/zoneinfo.html

---

About This Guide

This technical guide consolidates established calendrical rules and practical engineering experience building cross-time-zone, leap-year-accurate date utilities. It is intended for developers, product managers, and QA engineers who need correct, explainable age computations at scale.

---

{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "Why does my age differ by a day on different sites?",
      "acceptedAnswer": {"@type": "Answer", "text": "Different tools handle time zones, DST, and inclusive vs exclusive day counts differently. Normalizing to UTC for totals and documenting policies avoids ambiguity."}
    },
    {
      "@type": "Question",
      "name": "How should we handle Feb 29 birthdays?",
      "acceptedAnswer": {"@type": "Answer", "text": "Choose a policy (Feb 28 or Mar 1) and apply it consistently. Offer a setting for global audiences and explain the implications."}
    },
    {
      "@type": "Question",
      "name": "Is a month a fixed number of days?",
      "acceptedAnswer": {"@type": "Answer", "text": "No. Months vary from 28 to 31 days. Use calendar-aware math rather than fixed day counts."}
    },
    {
      "@type": "Question",
      "name": "Do time zones matter if I only need years and months?",
      "acceptedAnswer": {"@type": "Answer", "text": "Yes. The local calendar date at the \"now\" instant depends on time zone. Compute parts in the user’s IANA time zone."}
    },
    {
      "@type": "Question",
      "name": "Should I count the birth day in total days?",
      "acceptedAnswer": {"@type": "Answer", "text": "It’s a product choice. Many tools use exclusive counting. Whatever you choose, disclose it and test edge cases."}
    }
  ]
}