Methodik der Altersberechnung

Das Alter in Jahren-Monaten-Tagen zu berechnen, klingt trivial. Ist es nicht. Der naive Ansatz „heute minus Geburtstag geteilt durch 365,25“ driftet etwa einen Tag alle vier bis sieben Jahre, weil echte Jahre keine konstante Anzahl von Tagen haben. Der korrekte Algorithmus nutzt Kalender-Borgen – dieselbe Logik wie die Subtraktion in der Grundschule, aber mit „Ziffern“ variabler Länge.

Der Monats-Borrow-Algorithmus

Gegeben ein Geburtsdatum (bY-bM-bD) und heute (tY-tM-tD):

1. Jahresdifferenz: tY − bY.
2. Monatsdifferenz: tM − bM. Falls negativ, borge 1 von der Jahreszählung: ziehe 1 von der Jahresdifferenz ab, addiere 12 zur Monatsdifferenz.
3. Tagesdifferenz: tD − bD. Falls negativ, borge 1 von der Monatszählung: ziehe 1 von der Monatsdifferenz ab, addiere die Länge des Vormonats zur Tagesdifferenz.

Schritt 3 ist die Stelle, an der die meisten Implementierungen scheitern. Die „Länge des Vormonats“ ist keine konstante 30 – sie ist 28, 29, 30 oder 31, je nach Monat und (für Februar) je nach Jahr.

Durchgerechnetes Beispiel

Geburt: 1990-12-31. Heute: 2026-03-15.

1. Jahresdifferenz: 2026 − 1990 = 36.
2. Monatsdifferenz: 3 − 12 = −9. Borgen: Jahresdifferenz sinkt auf 35, Monatsdifferenz wird 3.
3. Tagesdifferenz: 15 − 31 = −16. Borgen: Monatsdifferenz sinkt auf 2, Tagesdifferenz += Länge des Vormonats. Der Vormonat ist Februar 2026 (28 Tage, kein Schaltjahr). Tagesdifferenz = −16 + 28 = 12.

Ergebnis: 35 Jahre, 2 Monate, 12 Tage.

Der Vormonatslängen-Trick

Der sauberste Weg, in JavaScript zu fragen „wie lang war der Vormonat?“:

new Date(year, month, 0).getDate()
// Returns the last day of (month - 1).
// Day 0 of month N is interpreted as day -0 = last day of N-1.

Dies behandelt die Februar-Schaltjahr-Korrektheit automatisch, weil Date es weiß. new Date(2024, 2, 0).getDate() gibt 29 zurück; new Date(2023, 2, 0).getDate() gibt 28 zurück.

Schaltjahr-Geburtstage (29. Februar)

Am 29. Februar geborene Menschen werfen eine wiederkehrende Frage auf: wann ist ihr Geburtstag in Nicht-Schaltjahren? Zwei Konventionen:

• Auf den 1. März rollen – Standard in UK, Hongkong.
• Auf den 28. Februar rollen – Standard in USA, Taiwan, Neuseeland. Der Rechner nutzt diese.

Die Wahl beeinflusst, wann der Moment „du bist N geworden“ in Nicht-Schaltjahren stattfindet. Für die meisten Zwecke spielt es keine Rolle – das zugrunde liegende Geburtsdatum ist weiterhin der 29. Februar, und der Unterschied beträgt einen Tag pro Nicht-Schaltjahr.

Warum „Tage / 365,25“ driftet

365,25 ist die mittlere Länge eines Jahres über einen 400-jährigen gregorianischen Zyklus. Jedes einzelne Jahr ist 365 oder 366. Über kurze Zeitfenster ist der Mittelwert keine gute Näherung:

• 4 Jahre enthalten genau 1 Schaltjahr → 1461 Tage → genau 365,25. Gut.
• 3 Jahre ab 1. März 2021 → 1095 Tage. Geteilt durch 365,25 = 2,998… → gerundet, 3 Jahre. Korrekt.
• 3 Jahre ab 1. März 2020 → 1096 Tage (enthält 29. Feb. 2024 – Moment, nein, enthält ihn nicht). Immer noch 1095 → gleich.
• Die Drift kommt von der Jahrhundertregel: 1900 war kein Schaltjahr (teilbar durch 100, nicht durch 400). 2000 war es. Das Berechnen von Altern, die 1900 oder 2100 überspannen, mit der 365,25-Näherung erzeugt sichtbare Fehler auf Tagesebene.

Für die Altersberechnung ist Kalender-Borgen immer exakt. Die naive Näherung ist für eine Überschlagsrechnung in Ordnung, aber falsch für alles, was zu einem Reisepass oder einer Geburtsurkunde passen muss.

Algorithmusdetails: Monats-Borgen vollständig

Die vollständige Referenzimplementierung ist kurz genug, um sie inline zu reproduzieren; die Überraschung ist, wie wenige Verzweigungen sie braucht, sobald der Tag-0-Trick das Problem der variablen Monatslänge behandelt.

function age(birth: Date, today: Date) {
  let y = today.getFullYear() - birth.getFullYear();
  let m = today.getMonth() - birth.getMonth();
  let d = today.getDate() - birth.getDate();
  if (d < 0) {
    // Borrow days from previous month — day 0 returns last day of previous month.
    const prevMonthLen = new Date(today.getFullYear(), today.getMonth(), 0).getDate();
    d += prevMonthLen;
    m -= 1;
  }
  if (m < 0) {
    m += 12;
    y -= 1;
  }
  return { years: y, months: m, days: d };
}

Der Algorithmus läuft in O(1)-Zeit ohne Division, ohne Gleitkommaarithmetik und ohne Kalenderbibliotheken. Die einzige spezifikationsgetriebene Verzweigung ist die Schaltjahrbehandlung – und selbst die wird an Date delegiert, das die gregorianische Regel (jedes durch 4 teilbare Jahr außer Jahrhundertjahren, die nicht durch 400 teilbar sind) aus ECMA-262 implementiert.

Im Vergleich zum naiven Tageszählungsansatz für eine Spanne von 100 Jahren:

Quellen & Referenzen

Die Schaltjahrregel ist die ursprüngliche gregorianische Reform von 1582 (Inter Gravissimas); das Datumsformat, das wir akzeptieren, ist ISO 8601; der Vormonatslängen-Trick ist wohldefiniertes ECMAScript-Verhalten aus ECMA-262. Die Roll-Konventionen für den 29.-Februar- Geburtstag sind jurisdiktionsspezifisch und gehen auf nationale Gesetzgebung zurück – siehe unseren Leitfaden zu Altersberechnungsmethoden für die Jurisdiktionstabelle. UK und Hongkong rollen auf den 1. März gemäß dem Births and Deaths Registration Act von 1953; USA, Neuseeland und Taiwan nutzen den 28. Februar per Verwaltungskonvention. Siehe den Quellenblock unten.

Annahmen & Einschränkungen

• Nur gregorianischer Kalender. Hidschri-, hebräische, chinesisch-lunare und julianische Kalender benötigen andere Algorithmen; der Umrechner bietet keine Auswahl des Kalendersystems.
• Nur Datum, nicht Datum-Zeit. Eingaben werden auf Mitternacht in der lokalen Zeitzone des Nutzers gekürzt. Sommerzeitwechsel beeinflussen das Ergebnis nicht.
• 29. Feb. → 28. Feb. rollen. Wir nutzen standardmäßig die US-Konvention. Nutzer in UK-/HK- Jurisdiktionen sollten in Nicht-Schaltjahren einen Tag zur „du bist N geworden“-Markierung addieren.
• Keine Unterstützung vor der gregorianischen Einführung. Geburtsdaten vor dem 15.10.1582 nutzen die proleptisch- gregorianische Erweiterung – historisch wären diese als julianische Daten erfasst und für den modernen Vergleich um 10–13 Tage nach vorne verschoben worden.
• Keine Schaltsekundenbehandlung. Schaltsekunden beeinflussen die Kalendertag-Arithmetik nicht; wenn Sie UTC-vs.-TAI-Präzision brauchen, nutzen Sie ein anderes Werkzeug.
• Zukünftige Daten geben null zurück, nicht negativ. Ein negatives Alter ist fast immer ein UX-Fehler und kein legitimes Ergebnis.

Randfälle, die der Rechner behandelt

• Zukünftige Geburtsdaten – wir geben null statt negativer Alter zurück. Ein negatives Alter ist eine Fehlerfläche.
• Heute gleich Geburtsdatum – 0 Jahre, 0 Monate, 0 Tage.
• Über Sommerzeitwechsel hinweg – der Rechner nutzt reine Datums-Mathematik (keine Zeiten), sodass Sommerzeitwechsel das Ergebnis nicht beeinflussen.