Methodik für Datum & Zeit

Datums- und Zeitarithmetik ist eine der am häufigsten versuchten, fehleranfälligsten Code-Kategorien in jeder großen Codebasis. Die vier Tools in unserem Datum-&-Zeit- Cluster nehmen sich jeweils ein anderes Teilproblem vor; diese Seite erklärt die Mathematik hinter jedem.

Altersrechner — kalenderbewusstes Borgen

Das Alter in Jahren-Monaten-Tagen ist nicht einfach „heute minus Geburtstag geteilt durch 365,25“ — diese Näherung akkumuliert alle 4–7 Jahre einen Tag Fehler. Der korrekte Algorithmus verwendet kalendarisches Borgen:

1. Jahresdifferenz berechnen: now.year − birth.year.
2. Monatsdifferenz berechnen. Wenn now.month < birth.month, 12 Monate von der Jahreszahl borgen.
3. Tagesdifferenz berechnen. Wenn now.day < birth.day, Tage von der Monatszahl borgen, unter Verwendung der tatsächlichen Länge des vorherigen Kalendermonats.

Schritt 3 ist dort, wo naiver Code scheitert. Die „Länge des vorherigen Monats“ ist nicht 30 oder 31 — sie hängt davon ab, welcher vorherige Monat es ist (Februar hat 28 oder 29, der Rest 30 oder 31). Unser Altersrechner verwendet new Date(year, month, 0) (das den letzten Tag des vorherigen Monats zurückgibt), um jedes Mal die richtige Zahl zu erhalten, einschließlich Schaltjahren.

Durchgerechnetes Beispiel

Geburt: 1990-12-31. Heute: 2026-05-14. Jahresdifferenz: 36. Monatsdifferenz: −7 (Mai minus Dezember). Ein Jahr borgen, Monatsdifferenz wird 5. Tagesdifferenz: 14 − 31 = −17. Einen Monat borgen; der vorherige Monat ist April mit 30 Tagen, also 30 hinzufügen, was eine Tagesdifferenz von 13 ergibt. Ergebnis: 35 Jahre, 4 Monate, 13 Tage.

Datumsdifferenz — drei Einheiten, ein Nenner

Das Datumsdifferenz- Tool gibt den Abstand zwischen zwei Daten gleichzeitig in Tagen, Wochen und Stunden an. Die Mathematik ist unkompliziert:

days = (b.getTime() − a.getTime()) / 86_400_000
weeks = days / 7 · hours = days × 24

Die Feinheit ist die Zeitzonenbehandlung. Beide Daten werden vor der Subtraktion auf UTC-Mitternacht normalisiert, sodass DST-Übergänge keine gebrochenen Tage einführen. Eine Datumsdifferenz, die eine Zeitumstellung im Frühjahr überspannt, ist immer noch eine ganzzahlige Anzahl von Tagen, wie es Nutzer erwarten.

Werktage — Montag bis Freitag zwischen zwei Daten

Der Werktagezähler verwendet den denkbar einfachsten Algorithmus: jeden Kalendertag zwischen den beiden Daten durchlaufen und einen Zähler erhöhen, wenn der Wochentag Montag–Freitag ist.

Bei ~250 Werktagen pro Jahr und einer Date-Objekt-Konstruktion, die im modernen V8 durchschnittlich ~1 µs dauert, ist dies für jeden Datumsbereich unter einem Jahrhundert in Mikrosekunden abgeschlossen. Wir verwenden keine geschlossene Formel, weil sie nur unwesentlich schneller und deutlich schwerer zu lesen ist.

Was nicht enthalten ist: nationale Feiertage. Die Feiertagsbeobachtung variiert nach Land, nach Jahr (die meisten sind datumsfest, aber eine bedeutende Teilmenge bewegt sich mit dem Mondkalender oder ist als „n-ter Wochentag des Monats“ definiert) und nach Branche. Wir müssten aus einem kuratierten Datensatz schöpfen, um dies verantwortungsvoll zu tun; das Werktage-Tool bleibt absichtlich werktagsbasiert.

Zeitzonenkonverter — IANA-tzdata + Intl.DateTimeFormat

Zeitzonen sind politische Konstrukte, keine geografischen, und ihre Regeln ändern sich. Beginndaten der Sommerzeit, Experimente mit ganzjähriger Sommerzeit, Teilungen und Zusammenführungen, wenn Länder sich neu organisieren — all dies ist im IANA-tzdata-Bundle erfasst, das mit jedem modernen Betriebssystem ausgeliefert wird.

Unser Zeitzonenkonverter erreicht diese Daten über das im Browser eingebaute Intl.DateTimeFormat. Wir bündeln nie unsere eigenen tzdata. Das ist wichtig, weil:

• tzdata wird mehrmals im Jahr aktualisiert, wenn Länder ihre Regeln ändern.
• Eine eigene Kopie zu bündeln würde diese Daten zur Build-Zeit einfrieren.
• Die tzdata auf Betriebssystemebene werden vom OS-Anbieter in einem Sicherheitsrhythmus aktualisiert, der schneller ist als unserer.

Der Wanduhr-Umrechnungsalgorithmus

Gegeben „14:00 am 2026-07-04 in Europe/Istanbul, wie spät ist es in America/Los_Angeles?“:

1. „14:00 am 2026-07-04“ als UTC-Zeitstempel behandeln (nennen wir ihn guess).
2. Intl.DateTimeFormat fragen: welchen Offset hat Europe/Istanbul bei guess? (UTC+3.)
3. Anpassen: der tatsächliche UTC-Augenblick ist guess − 3 Stunden.
4. Diesen UTC-Augenblick auf der Wanduhr von Los_Angeles rendern.

Dies behandelt Halbstundenzonen (Indien, UTC+5:30) und 45-Minuten-Zonen (Nepal, UTC+5:45) ohne Sonderbehandlung. Der einzige Fall, der bricht, ist die „Frühjahrslücke“ — 2:30 Uhr existiert in einer Zone, die von 2:00 auf 3:00 springt, nicht —, aber der Rechner gibt das um eine Stunde verschobene Ergebnis zurück, statt zu scheitern, was immer noch nützliche Information ist.

Der ISO-8601-Standard

Alle Datumseingaben in der Oberfläche verwenden das ISO-8601-Format (YYYY-MM-DD). Alle intern erzeugten Date-Objekte sind an der Grenze zeitzonen-naiv und werden erst zeitzonenbewusst, wenn sie in den Zeitzonenkonverter übergehen. Die Ausgabe von Intl.DateTimeFormat ist in der Browsersprache des Nutzers lokalisierungsbewusst; die zugrunde liegenden Daten sind für Speicherung und Serialisierung stets ISO 8601.