Datum-Addieren/Subtrahieren-Rechner

Ein Rechner zum Addieren oder Subtrahieren von Daten ermittelt ein Zieldatum, indem er ein Startdatum um Tage, Wochen, Monate oder Jahre vor- oder zurücksetzt. Er hilft bei Vertragsfristen, Verlängerungen, Wiedervorlagen, Garantieenden, Projektterminen und Erinnerungen, ohne dass man den Kalender manuell abzählen muss. Die eigentliche Schwierigkeit liegt in den Kalendergrenzen: Monate sind unterschiedlich lang, Schaltjahre verändern den Februar, und ein Datum wie der 31. Januar existiert im Folgemonat nicht immer. Das Werkzeug liefert schnell ein praktisches Kalenderdatum für die Planung. Es zählt jedoch nur normale Kalenderzeit; Arbeitstage, Feiertage, regionale Regeln und rechtliche Fristen müssen gesondert geprüft werden.

Die Datumsarithmetik in diesem Tool basiert auf dem proleptischen Gregorianischen Kalender, wie er vom ECMAScript-Date-Objekt implementiert wird. Monate sind in JavaScript 0-indiziert (Januar = 0, Dezember = 11), was die häufigste Fehlerquelle für Off-by-one-Fehler in Datumscode darstellt. Das Addieren von Tagen ist unkompliziert: new Date(d.getTime() + n * 86_400_000). Das Addieren von Monaten ist schwieriger, da Monate 28, 29, 30 oder 31 Tage haben: Die Standardanweisung date.setMonth(date.getMonth() + n) läuft über, wenn der resultierende Monat kürzer ist als der Ausgangstag – der 31. Januar plus 1 Monat ergibt den 3. März statt den 28. Februar (die Engine trägt die überschüssigen 3 Tage in den März vor). Dieses Tool erkennt den Überlauf durch Vergleich von date.getMonth() nach setMonth und begrenzt den Tag auf den letzten Tag des Zielmonats, wenn nötig, im Einklang mit dem Verhalten von moment.js, date-fns und Temporals Plain Date.add(). Schaltjahre folgen der standardmäßigen Gregorianischen Regel: Ein Jahr ist ein Schaltjahr, wenn es durch 4 teilbar ist, mit Ausnahme von Jahrhundertjahren, die zusätzlich durch 400 teilbar sein müssen. Daher sind 1900 und 2100 Gemeinjahre, während 2000 ein Schaltjahr war und 2024 ebenfalls eines ist. Dies ist relevant, wenn eine Berechnung den 29. Februar kreuzt: 29. Januar + 1 Monat + 1 Monat ergibt 2023 den 29. März, aber 2024 trifft der Überlauf auf den 29. Februar (ein gültiges Datum) und dann den 29. März, ohne dass eine Begrenzung nötig wäre. Die Jahresgrenze 1582 für den julianisch-gregorianischen Übergang wird hier ignoriert, da der proleptische Gregorianische Kalender die Regeln unbegrenzt zurückverlängert; Daten vor dem 15. Oktober 1582 sind technisch anachronistisch, liefern aber für moderne Zwecke korrekte Ergebnisse. Die Zeitzonenbehandlung ist eine separate Dimension: Date speichert intern einen UTC-Zeitpunkt und wendet die IANA-Zeitzone des Host-Systems (z. B. America/New_York, Asia/Shanghai) nur beim Aufruf von .getDate(), .month() oder .toLocaleString() an. Daraus ergeben sich zwei Fallstricke: (1) Ein Datum aus einem ISO-String ohne Z-Suffix ("2026-06-10") wird als Mitternacht UTC interpretiert, während "2026-06-10T00:00:00" ohne Z als lokale Mitternacht geparst wird – derselbe date.getDate()-Aufruf kann je nach UTC-Offset des Benutzers 9 oder 10 zurückgeben; (2) Zeitzonenwechsel im Frühjahr (Überspringen von 02:00–03:00) und Herbst (Wiederholung von 01:00–02:00) machen manche Arithmetik mehrdeutig, sodass eine "+24 Stunden"-Addition auf eine Wanduhrzeit stoßen kann, die 23 oder 25 Stunden entfernt ist. Für arbeitstägige, wochentagsbezogene oder feiertagsbewusste Arithmetik muss das Kalenderergebnis gegen eine regionsspezifische Feiertagsliste nachbearbeitet werden (z. B. über das npm-Paket date-holidays oder einen individuellen Kalender) anstatt sich auf den reinen Überlauf zu verlassen.

• JS-Date-Monate sind 0-indiziert: Januar = 0, Dezember = 11; Off-by-one ist der häufigste Fehler.
• setMonth-Überlauf: 31. Jan. + 1 Monat ergibt 3. Mär., nicht 28. Feb.; das Tool begrenzt auf das Monatsende, indem getMonth() nach setMonth verglichen wird.
• Schaltjahr: Durch 4 teilbar, aber Jahrhundertjahre müssen zusätzlich durch 400 teilbar sein (1900 nein, 2000 ja, 2024 ja).
• ISO 8601 ohne Z ("2026-06-10T00:00:00") wird als lokale Zeit geparst; mit Z ist es UTC – getDate() kann unterschiedliche Tage zurückgeben.
• Zeitzonenwechsel erzeugen 23-Stunden- und 25-Stunden-Tage; +24h-Addition ist nicht immer +1 Kalendertag.
• Tagesgenaue Mathematik ist exakt über getTime() + n * 86_400_000; längere Einheiten kaskadieren über setMonth/setFullYear mit Begrenzung.
• Arbeitstägliche und feiertagsbewusste Arithmetik muss über eine regionsspezifische Kalendertabelle ergänzt werden – nicht in der Engine selbst.