Viele Entwickler setzen mktime() ein, um mit Datums- und Zeitwerten in PHP zu arbeiten – doch sobald Sommerzeit, Zeitzonen oder eine vermeintlich einfache Tagesberechnung ins Spiel kommen, wird es schnell kompliziert.
I. Einstieg: Was macht PHP mktime() – und wo liegt das Problem?
Mit mktime() wandelst Du von ein Datum (Jahr, Monat, Tag, Stunde, Minute und Sekunde) scheinbar mühelos in einen Unix-Timestamp um. Doch in der Praxis sorgen Details wie die Zeitumstellung zwischen Sommerzeit und Winterzeit immer wieder für überraschende und schwer zu findende Fehler. Wer Zeiten zuverlässig berechnen will, darf sich nicht blind auf mktime() verlassen, sondern muss verstehen, was im Hintergrund passiert.
Wichtige Anwendungsfälle:
- Exaktes Festlegen eines Datums/Zeitpunkts für Berechnungen oder Vergleiche
- Monats- und Tagesberechnungen („letzter Tag im Monat“, „nächster Montag“)
- Validieren und Korrigieren fehlerhafter Benutzereingaben mit Datums- und Zeit-funktionen.
- Basis für alle „Wann ist etwas abgelaufen?“-Checks
mktime() ist mächtig – doch für alles, was die Sommerzeit berührt, solltest du genau prüfen, ob das Ergebnis stimmt.
II. Syntax und typische Anwendung
Die Verwendung von mktime() sieht auf den ersten Blick simpel aus – dennoch lohnt sich ein genauer Blick auf die Parameter und ihre Bedeutung, da sich mit kleinen Fehlern unbemerkt unerwartete Resultate einschleichen können.
Ab PHP 8:
mktime(int $stunde, ?int $minute = null, ?int $sekunde = null, ?int $monat = null, ?int $tag = null, ?int $jahr = null): int|false
Die Reihenfolge bleibt wie gewohnt: Stunde, Minute, Sekunde, Monat, Tag, Jahr. Die Funktion liefert einen Zeitstempel (int) oder false, wenn Werte ungültig sind.
Praktischer Kurzcode:
echo date('Y-m-d H:i:s', mktime(2, 0, 0, 3, 31, 2024));
/* Ergebnis hängt von der Zeitumstellung ab! */
III. Zeitumstellung: Die unterschätzte Fehlerquelle
Hier sitzt das eigentliche Problem: mktime() arbeitet mit der aktuellen Server-Zeitzone – inklusive Sommerzeit.
Im Frühling existieren bestimmte Zeitpunkte nicht. Beispiel: In Deutschland springt die Uhr von 2:00 Uhr direkt auf 3:00 Uhr. Das heißt, mktime(2, 30, 0, 3, 31, 2024) erzeugt etwas, was es gar nicht gibt. PHP rückt dann die Zeit automatisch auf den nächsten gültigen Zeitpunkt, meist 3:30 Uhr. Im Herbst gibt es die Zeit zwischen 2:00 und 3:00 Uhr zweimal – und du bekommst je nach Kontext unterschiedliche Timestamps zurück.
Beispiel: Zeitumstellung Frühjahr
date_default_timezone_set('Europe/Berlin');
echo date('Y-m-d H:i:s', mktime(2, 30, 0, 3, 31, 2024));
/* -> 2024-03-31 03:30:00, obwohl eigentlich 2:30! */
Du denkst, du hast „2:30 Uhr“, aber tatsächlich bekommst du „3:30 Uhr“ – und oft bleibt dieser Fehler unbemerkt.
Beispiel: Zeitumstellung Herbst
/* Am 27.10.2024 gibt es 2:30 Uhr doppelt! */
echo date('Y-m-d H:i:s', mktime(2, 30, 0, 10, 27, 2024));
/* PHP nimmt die zweite Instanz, kann aber je nach Version variieren */
Für alles, was in dieser Stunde passiert, kann es zu doppelten Buchungen, Erinnerungen oder Benachrichtigungen kommen.
Bittere Wahrheit:
Die automatische Korrektur von mktime() kaschiert diese Fehler. Was auf den ersten Blick praktisch wirkt, sorgt für böse Überraschungen in der Produktion, insbesondere bei der Verwendung von Timestamp.
IV. Wann solltest du mktime() meiden – und was stattdessen tun?
Immer, wenn deine Anwendung sensible Zeiträume abdecken muss, z. B. Buchungssysteme, Fristen, wiederkehrende Aufgaben, solltest du mktime() nicht allein verwenden.
Die bessere Wahl:
Nutze das objektorientierte DateTime-API von PHP, denn hier kannst du explizit festlegen, wie mit Zeitumstellungen umgegangen wird.
Praktischer Vergleich:
$dt = new DateTime('2024-03-31 02:30:00', new DateTimeZone('Europe/Berlin'));
echo $dt->format('Y-m-d H:i:s');
/* wirft Exception, weil dieser Zeitpunkt nicht existiert, oder rückt auf 03:30 */
So bekommst du eine Fehlermeldung oder zumindest ein direkt sichtbares Problem, statt stillschweigend einen falschen Wert.
DateTimeImmutable für zuverlässige Berechnungen:
$dt = new DateTimeImmutable('2024-10-27 01:30:00', new DateTimeZone('Europe/Berlin'));
$dt2 = $dt->modify('+1 hour');
echo $dt2->format('Y-m-d H:i:s');
/* 2024-10-27 02:30:00 (zweite Instanz der Zeit) */
Mit DateTime-Objekten kannst du gezielt prüfen, ob du im Sommer oder Winter bist – und die Zeitumstellung korrekt nachvollziehen.
V. Automatische Datumskorrektur und Zeitzone: Was mktime() trotzdem kann
Trotz aller Schwächen bei der Zeitumstellung bietet mktime() unschlagbare Vorteile bei einfachen Datumsberechnungen:
- Du kannst beliebig „über den Rand“ gehen (z. B. 32. Januar → 1. Februar).
- Du rechnest schnell mit Monats- und Jahreswechseln, ohne selbst den Kalender nachzuschlagen.
Beispiel:
/* Letzter Tag des Monats: */
echo date('Y-m-d', mktime(0, 0, 0, 3 + 1, 0, 2024));
/* 2024-03-31 */
/* Erster Tag nächster Monat: */
echo date('Y-m-d', mktime(0, 0, 0, 5 + 1, 1, 2025));
/* 2025-06-01 */
Aber auch hier gilt: mktime() arbeitet immer in der aktuellen Zeitzone. Änderst du das Zeitzonen-Setting, verschieben sich alle Ergebnisse. Setze daher die Zeitzone immer explizit am Anfang deines Skripts, damit du konsistente Ergebnisse bekommst.
VI. Best Practices aus der Praxis
-
Prüfe Zeitzone zu Beginn:
date_default_timezone_set('Europe/Berlin');
-
Überprüfe, ob dein Zeitstempel im Zeitumstellungsbereich liegt, wenn deine Anwendung präzise Zeitangaben erfordert, um die Anzahl der Sekunden zu ermitteln.
-
Validere Benutzereingaben und nutze, wo möglich, vierstellige Jahresangaben.
-
Weiche bei allem, was mit echten Uhrzeiten, Terminen, Buchungen oder Erinnerungen rund um März/Oktober zu tun hat, konsequent auf DateTimeImmutable aus.
-
Kommentiere und dokumentiere, warum du dich bewusst für mktime() oder eine Alternative entscheidest, wenn du mit timestamp arbeitest.
VII. Troubleshooting: Typische Fehlerquellen
-
Unerwartete Verschiebung durch Sommerzeit:
Du erwartest „2:30 Uhr“, PHP gibt „3:30 Uhr“ zurück.
Lösung: Vermeide mktime() für Zeitpunkte in der Umstellungsnacht, oder prüfe mit date_sunrise() und Zeitzonen-APIs.
-
Fehlende oder doppelte Ereignisse:
Bei wiederkehrenden Aufgaben im Oktober taucht ein Event zweimal auf.
Lösung: Nutze die eindeutigen Zeitzoneninformationen von DateTime.
-
Server läuft in UTC, du rechnest aber mit Berlin-Zeiten:
Deine Zeitstempel stimmen nicht mehr mit der realen Uhrzeit überein.
Lösung: Setze die Zeitzone gezielt und prüfe mit date_default_timezone_get().
VIII. Alternatives Vorgehen mit DateTime & Co.
So arbeitest du robust mit Zeiten:
$date = new DateTimeImmutable('2024-03-31 01:30:00', new DateTimeZone('Europe/Berlin'));
$datePlus1h = $date->modify('+1 hour');
echo $datePlus1h->format('Y-m-d H:i:s');
/* 2024-03-31 03:30:00, Sommerzeit übersprungen */
Du siehst: Mit DateTimeImmutable erkennst du, dass „2:30 Uhr“ gar nicht möglich ist. Das ist der große Vorteil gegenüber mktime() – du bekommst Fehler, keine falschen Ergebnisse.
IX. Changelog & Entwicklung
- PHP 8.0: Entfernte $is_dst.
- Aktuell: Zeitumstellung bleibt für mktime() ein Risiko – das Verhalten ist undokumentiert und kann sich zwischen PHP-Versionen ändern.
X. Persönliches Fazit
Ich kann mktime() für einfache, zeitzonenunabhängige Datumsrechnungen empfehlen, solange du garantiert nicht im Bereich der Zeitumstellung landest. Für alles andere – und immer dann, wenn du wirklich zuverlässig mit Kalenderdaten und Uhrzeiten arbeiten willst – solltest du auf DateTimeImmutable setzen. Die Zeitumstellung ist keine theoretische Stolperfalle, sondern trifft dich in der Praxis oft genau dann, wenn es kritisch wird: Bei wiederkehrenden Terminen, Kalenderimporten, oder im Zusammenspiel mit externen Systemen.
Ich erlebe es fast jedes Jahr aufs Neue: Teams übersehen die Zeitumstellung, wundern sich über falsche Erinnerungen, doppelte Einträge oder fehlgeschlagene Buchungen – und die Ursache liegt oft an mktime(). Wer das einmal erlebt hat, vertraut lieber auf die modernen PHP-Klassen.
Schlussgedanke:
Manche Fehler schleichen sich unbemerkt ein und explodieren erst bei der Zeitumstellung. mktime() macht vieles einfach – doch wer Wert auf Präzision und Wartbarkeit legt, setzt heute auf DateTimeImmutable und explizite Zeitzonenlogik.
Du sparst dir Ärger, Supportfälle und peinliche Bugs – und kannst dich auf das verlassen, was dein Code tut.
