Monate zu einem Datum addieren ist kniffliger als es klingt

7 Tage zu einem Datum zu addieren ist einfach. Du nimmst eine Zahl, addierst 7, fertig. Einen Monat hinzuzufügen ist ein völlig anderes Problem.

Das Problem ist, dass Monate unterschiedlich lang sind. Januar hat 31 Tage. Februar hat 28, manchmal 29. Wenn du am 31. Januar bist und einen Monat addierst, landest du am 31. Februar — der existiert nicht.

Jede Kalenderbibliothek, jede Tabellenkalkulation und jede Datenbank hat eine eigene Meinung, was man dann machen sollte.

Was die meisten Tools machen

Das häufigste Verhalten ist, zum letzten Tag des Zielmonats zu springen. 31. Januar + 1 Monat = 28. Februar (oder 29 in einem Schaltjahr). 31. März + 1 Monat = 30. April.

Das heißt End-of-Month Clamping und ist das Standard-Verhalten von Excel, Google Sheets, Pythons dateutil und den meisten Datums-Bibliotheken.

Das ist sinnvoll, erzeugt aber ein subtiles Problem: Die Operation ist nicht umkehrbar. Wenn du einen Monat zum 31. Januar addierst, erhältst du den 28. Februar. Subtrahierst du dann einen Monat, bekommst du den 28. Januar — nicht den 31. Januar. Du hast drei Tage verloren.

Der Überlauf-Ansatz

Manche Systeme lassen das Datum stattdessen in den nächsten Monat überlaufen, statt es zu begrenzen. 31. Januar + 1 Monat = 3. März (oder 2. März in einem Schaltjahr, da Februar 29 Tage hat).

Das bewahrt die Gesamtzahl der Tage, aber das Ergebnis liegt in einem völlig anderen Monat als beabsichtigt. Aus Nutzersicht ist das überraschend und normalerweise falsch.

SQLs INTERVAL-Syntax in manchen Datenbanken verhält sich so, je nach Konfiguration. Es ist leicht, sich zu verbrennen, wenn du nicht weißt, welches Verhalten du verwendest.

Jahresaddition hat das gleiche Problem

29. Februar existiert nur in Schaltjahren. Addiere ein Jahr zum 29. Februar 2024, und du erhältst 29. Februar 2025 — das existiert nicht. Mit Clamping bekommst du 28. Februar 2025.

Gleiches Verhalten, gleiche Kompromisse.

Wann das zu echten Bugs führt

Abonnement-Abrechnung ist das Klassiker-Beispiel. Ein Nutzer meldet sich am 31. Januar an. Das nächste Abrechnungsdatum ist 28. Februar. Dann 28. März. Dann 28. April. Nach dem ersten Monat werden sie jeden Monat 2–3 Tage früher abgerechnet, als sie erwarten würden.

Wiederkehrende Kalendereinträge haben das gleiche Problem. „Jeden Monat am 31." wird stillschweigend zu „jeden Monat am letzten Tag" für Monate, die nicht bis zum 31. reichen.

Kreditrückzahlungspläne, Gehaltstage und alles mit „monatlicher" Wiederholung trifft diesen Spezialfall irgendwann.

Tage addieren hat dieses Problem nicht

Wenn du „30 Tage ab jetzt" ausdrücken musst statt „einen Monat ab jetzt", addiere einfach 30 Tage. Das Ergebnis ist eindeutig und reversibel.

Die Unterscheidung ist wichtig: Ein 30-Tage-Abrechnungszyklus und ein monatlicher Abrechnungszyklus sind nicht dasselbe und divergieren schnell über die Zeit.

Was du in deinem Tool oder deiner Bibliothek überprüfen solltest

Bevor du dich auf Datums-Addition in einem System verlässt, lohnt es sich zu wissen:

• Begrenzt es Monatsend-Daten oder lässt es überfluten?
• Bewahrt es den Tag des Monats über mehrere Additionen, oder grenzt es jedes Mal neu ein?
• Was passiert bei Schaltjahr-Spezialfällen wie 29. Feb. + 1 Jahr?

Der Date Calculator zeigt dir das genaue Ergebnis für jedes Datum und jeden Offset — nützlich, um vor der Umsetzung in Code zu überprüfen.