Wer einzelne Datums- und Zeitkomponenten wie Tag, Monat und Jahr in einen Unix-Timestamp umwandeln will, kommt an mktime() kaum vorbei. Die Funktion ist seit den Anfängen von PHP verfügbar und erledigt diese Aufgabe zuverlässig, solange man ihre Eigenheiten kennt. Besonders die automatische Datumskorrektur macht mktime() zu einem nützlichen Werkzeug für Kalenderberechnungen. Gleichzeitig lauern Stolperfallen bei der Zeitumstellung, die in der Praxis immer wieder für Überraschungen sorgen.
Was ist ein Unix-Timestamp?
Bevor wir in die Details von mktime() einsteigen, kurz zur Grundlage: Ein Unix-Timestamp ist die Anzahl der Sekunden seit dem 1. Januar 1970, 00:00:00 Uhr UTC. Dieser Zeitpunkt wird als Unix-Epoche bezeichnet. Der Timestamp 0 steht also für den 1. Januar 1970, und 86400 für den 2. Januar 1970 (ein Tag hat 86.400 Sekunden).
Auf 32-Bit-Systemen endet der darstellbare Bereich am 19. Januar 2038 um 03:14:07 UTC. Dieses sogenannte Y2K38-Problem betrifft moderne 64-Bit-Systeme nicht mehr, da dort Timestamps weit über das Jahr 2038 hinaus funktionieren. Wenn du mit aktuellem PHP (64-Bit) arbeitest, brauchst du dir darüber keine Sorgen zu machen.
Syntax und Parameter von mktime()
Die Funktion erwartet bis zu sechs Parameter in einer festen Reihenfolge. Seit PHP 8.0 ist der erste Parameter ($stunde) verpflichtend, alle weiteren sind optional und werden bei Weglassen aus der aktuellen Serverzeit übernommen.
mktime(
int $stunde,
?int $minute = null,
?int $sekunde = null,
?int $monat = null,
?int $tag = null,
?int $jahr = null
): int|false
Die Reihenfolge Stunde, Minute, Sekunde, Monat, Tag, Jahr ist ungewöhnlich und weicht von der typischen Datumsschreibweise ab. Ein häufiger Fehler ist es, Monat und Tag zu vertauschen. Die Funktion gibt einen ganzzahligen Timestamp zurück oder false, wenn die Eingabewerte ungültig sind.
<?php
date_default_timezone_set('Europe/Berlin');
$ts = mktime(14, 30, 0, 6, 15, 2025);
echo date('d.m.Y H:i:s', $ts);
// 15.06.2025 14:30:00
?>
Formulareingaben in einen Timestamp umwandeln
Der häufigste Einsatzzweck von mktime() in der Praxis: Ein Benutzer gibt ein Datum über ein HTML-Formular ein, und du möchtest daraus einen Timestamp erzeugen, um ihn in der Datenbank zu speichern oder für Berechnungen zu verwenden. Dabei ist es wichtig, die Eingabe vorher mit checkdate() zu validieren.
<?php
$iTag = (int) ($_POST['tag'] ?? 0);
$iMonat = (int) ($_POST['monat'] ?? 0);
$iJahr = (int) ($_POST['jahr'] ?? 0);
if (!checkdate($iMonat, $iTag, $iJahr)) {
echo 'Ungültiges Datum eingegeben.';
} else {
$iTimestamp = mktime(0, 0, 0, $iMonat, $iTag, $iJahr);
echo 'Timestamp: ' . $iTimestamp;
echo '<br>Datum: ' . date('d.m.Y', $iTimestamp);
}
?>
checkdate() prüft, ob ein Datum tatsächlich existiert. So wird zum Beispiel der 30. Februar korrekt als ungültig erkannt. Ohne diese Validierung würde mktime() das Datum stillschweigend korrigieren und den 30. Februar als 2. März interpretieren.
Automatische Datumskorrektur
Eine der nützlichsten Eigenschaften von mktime() ist die automatische Korrektur ungültiger Datumswerte. Gibst du den 32. Januar an, rechnet PHP das automatisch in den 1. Februar um. Das ermöglicht elegante Kalenderberechnungen, ohne selbst prüfen zu müssen, wie viele Tage ein Monat hat.
<?php
/* Letzter Tag eines Monats ermitteln */
$iMonat = 3; // März
$iJahr = 2024;
$iLetzterTag = date('d', mktime(0, 0, 0, $iMonat + 1, 0, $iJahr));
echo "Letzter Tag im März $iJahr: $iLetzterTag";
// Letzter Tag im März 2024: 31
?>
Der Trick: Tag 0 des Folgemonats entspricht dem letzten Tag des aktuellen Monats. So findest du den letzten Tag eines beliebigen Monats, ohne eine Tabelle der Monatslängen pflegen zu müssen.
<?php
/* 90 Tage in die Zukunft berechnen */
$iFutur = mktime(0, 0, 0, date('m'), date('d') + 90, date('Y'));
echo 'In 90 Tagen ist der ' . date('d.m.Y', $iFutur);
?>
Diese Korrektur funktioniert auch rückwärts: Tag -1 ergibt den vorletzten Tag des Vormonats. Beachte aber, dass mktime() dabei immer in der aktuellen Server-Zeitzone rechnet. Setze daher die Zeitzone immer explizit am Anfang deines Skripts.
Zeitumstellung: Die unterschätzte Fehlerquelle
Hier sitzt das eigentliche Risiko bei mktime(): Die Funktion arbeitet mit der eingestellten Server-Zeitzone, inklusive Sommerzeit. Im Frühling existieren bestimmte Zeitpunkte schlicht nicht. In Deutschland springt die Uhr am letzten Sonntag im März von 2:00 Uhr direkt auf 3:00 Uhr. Das bedeutet: mktime(2, 30, 0, 3, 30, 2025) erzeugt einen Zeitpunkt, den es nie gegeben hat. PHP rückt die Zeit dann automatisch auf den nächsten gültigen Zeitpunkt vor, meistens 3:30 Uhr.
<?php
date_default_timezone_set('Europe/Berlin');
echo date('Y-m-d H:i:s', mktime(2, 30, 0, 3, 30, 2025));
/* 2025-03-30 03:30:00 statt 02:30:00! */
?>
Im Herbst gibt es das umgekehrte Problem: Die Uhr wird von 3:00 auf 2:00 Uhr zurückgestellt. Die Stunde zwischen 2:00 und 3:00 Uhr existiert dann zweimal, und du bekommst je nach PHP-Version unterschiedliche Timestamps zurück.
<?php
/* Am 26.10.2025 gibt es 2:30 Uhr doppelt! */
echo date('Y-m-d H:i:s', mktime(2, 30, 0, 10, 26, 2025));
/* PHP nimmt eine der beiden Instanzen */
?>
Das Tückische: mktime() meldet keinen Fehler. Die automatische Korrektur kaschiert das Problem, und du merkst es erst, wenn in der Produktion doppelte Buchungen oder fehlende Erinnerungen auftauchen.
gmmktime(): Die UTC-Alternative
Wenn du Zeitzonen-Probleme komplett umgehen willst, ist gmmktime() eine einfache Lösung. Die Funktion hat exakt dieselbe Signatur wie mktime(), rechnet aber immer in UTC. Sommerzeit und Winterzeit spielen keine Rolle.
<?php
/* Vergleich: mktime() vs. gmmktime() */
date_default_timezone_set('Europe/Berlin');
$ts1 = mktime(2, 30, 0, 3, 30, 2025);
$ts2 = gmmktime(2, 30, 0, 3, 30, 2025);
echo date('H:i', $ts1); // 03:30 (korrigiert!)
echo gmdate('H:i', $ts2); // 02:30 (exakt)
?>
Verwende gmmktime(), wenn du mit UTC-Timestamps arbeitest, zum Beispiel für API-Kommunikation, Log-Dateien oder die Speicherung in Datenbanken. In solchen Fällen rechnest du intern in UTC und konvertierst erst bei der Ausgabe in die lokale Zeitzone des Benutzers.
strtotime() als Alternative für Datumsstrings
Nicht immer liegen die Datumsbestandteile einzeln vor. Wenn du einen Datumsstring wie "2025-06-15" oder "next monday" in einen Timestamp umwandeln willst, ist strtotime() die bessere Wahl. Die Funktion akzeptiert englischsprachige Datumsbeschreibungen und relative Ausdrücke.
<?php
/* Fester Datumsstring */
echo date('d.m.Y', strtotime('2025-06-15'));
// 15.06.2025
/* Relative Angaben */
echo date('d.m.Y', strtotime('+7 days'));
echo date('d.m.Y', strtotime('next monday'));
echo date('d.m.Y', strtotime('last day of this month'));
?>
Wann welche Funktion? Verwende mktime(), wenn dir Tag, Monat, Jahr als einzelne Zahlen vorliegen, zum Beispiel aus Formularfeldern oder einer Datenbank-Abfrage. Verwende strtotime(), wenn du einen fertigen Datumsstring oder relative Zeitangaben verarbeiten willst. Für zeitzonen-sensible Anwendungen ist DateTimeImmutable in beiden Fällen die sicherere Wahl.
DateTimeImmutable statt mktime()
Für alles, was über einfache Datumsrechnungen hinausgeht, empfiehlt sich das objektorientierte DateTime-API von PHP. Besonders DateTimeImmutable ist die robustere Alternative zu mktime(), weil du die Zeitzone explizit angeben und Zeitumstellungen kontrolliert behandeln kannst.
<?php
$oTz = new DateTimeZone('Europe/Berlin');
/* DateTimeImmutable statt mktime() */
$oDatum = new DateTimeImmutable('2025-03-30 01:30:00', $oTz);
$oSpaeter = $oDatum->modify('+1 hour');
echo $oSpaeter->format('Y-m-d H:i:s');
/* 2025-03-30 03:30:00, Sommerzeit korrekt berücksichtigt */
?>
Im Gegensatz zu mktime() verändert DateTimeImmutable das Originalobjekt nicht. Jede Manipulation erzeugt ein neues Objekt, was Seiteneffekte verhindert und den Code vorhersagbarer macht.
Validierung mit createFromFormat()
Ein verbreiteter Irrtum ist, dass DateTime bei ungültigen Zeitpunkten eine Exception wirft. Das stimmt nicht: Auch DateTime korrigiert ungültige Werte stillschweigend, genau wie mktime(). Um Fehler zu erkennen, nutze DateTimeImmutable::createFromFormat() in Kombination mit getLastErrors():
<?php
$oDatum = DateTimeImmutable::createFromFormat(
'Y-m-d',
'2025-02-30'
);
$aFehler = DateTimeImmutable::getLastErrors();
if ($aFehler['warning_count'] > 0) {
echo 'Datum wurde korrigiert!';
/* z.B. 30. Feb. wird zu 2. März */
}
?>
So erkennst du, ob PHP eine stille Korrektur vorgenommen hat, und kannst darauf reagieren, statt fehlerhafte Daten in die Datenbank zu schreiben.
Timestamps vergleichen und Differenzen berechnen
Da Timestamps einfache Ganzzahlen sind, kannst du sie direkt mit Vergleichsoperatoren verwenden. Das macht Prüfungen wie "Liegt Datum A vor Datum B?" trivial.
<?php
$tsStart = mktime(0, 0, 0, 1, 15, 2025);
$tsEnde = mktime(0, 0, 0, 3, 20, 2025);
if ($tsStart < $tsEnde) {
$iDiffTage = ($tsEnde - $tsStart) / 86400;
echo "Differenz: $iDiffTage Tage";
// Differenz: 64 Tage
}
?>
Beachte: Die Division durch 86400 liefert nur dann exakte Tage, wenn keine Zeitumstellung dazwischen liegt. Für präzise Tagesdifferenzen über Sommerzeit-Grenzen hinweg nutze besser DateTimeImmutable::diff(), die auch Schaltjahre und Kalenderwochen korrekt berücksichtigt.
Best Practices
Die folgenden Empfehlungen helfen dir, typische Fehler mit mktime() zu vermeiden und robusten Code zu schreiben.
- Zeitzone immer explizit setzen: Rufe
date_default_timezone_set('Europe/Berlin') am Anfang deines Skripts auf. So vermeidest du Überraschungen, wenn der Server in einer anderen Zeitzone läuft. - Benutzereingaben validieren: Verwende
checkdate(), bevor du Werte an mktime() übergibst. Ohne Validierung korrigiert mktime() ungültige Daten stillschweigend. - Vierstellige Jahreszahlen verwenden: Zweistellige Jahre werden von PHP interpretiert (0-69 als 2000-2069, 70-99 als 1970-1999). Nutze immer vierstellige Jahreszahlen für Klarheit.
- Für Zeitzonen-sensible Logik DateTime nutzen: Buchungssysteme, Fristen, wiederkehrende Aufgaben und alles rund um die Zeitumstellung gehört in die Hände von DateTimeImmutable.
- Entscheidungen dokumentieren: Wenn du dich bewusst für mktime() statt DateTime entscheidest, schreibe einen Kommentar ins Script. Das hilft beim späteren Debugging.
Troubleshooting: Typische Fehlerquellen
Hier findest du die häufigsten Probleme mit mktime() und wie du sie löst.
-
Unerwartete Verschiebung durch Sommerzeit: Du erwartest 2:30 Uhr, PHP gibt 3:30 Uhr zurück. Vermeide mktime() für Zeitpunkte in der Umstellungsnacht. Prüfe mit date_sun_info() und DateTimeZone::getTransitions(), wann die nächste Zeitumstellung stattfindet.
-
Fehlende oder doppelte Ereignisse: Bei wiederkehrenden Aufgaben im Oktober taucht ein Event zweimal auf. Nutze die eindeutigen Zeitzoneninformationen von DateTime, um zwischen der ersten und zweiten Instanz der doppelten Stunde zu unterscheiden.
-
Server läuft in UTC, du rechnest mit Berlin-Zeiten: Deine Zeitstempel stimmen nicht mit der realen Uhrzeit überein. Setze die Zeitzone gezielt mit date_default_timezone_set() und prüfe sie mit date_default_timezone_get().
-
mktime() gibt false zurück: Seit PHP 8.0 muss mindestens der Parameter $stunde angegeben werden. Ein Aufruf ohne Parameter wie mktime() erzeugt eine Deprecation-Warnung bzw. einen Fehler. Aktiviere error_reporting, um solche Probleme frühzeitig zu erkennen.
Häufig gestellte Fragen (FAQ)
Die folgenden Fragen tauchen in Foren und bei der täglichen Arbeit mit mktime() immer wieder auf.
Was ist der Unterschied zwischen mktime() und time()?
time() gibt den aktuellen Unix-Timestamp zurück, also die Sekunden seit dem 1. Januar 1970 bis jetzt. mktime() erzeugt einen Timestamp für einen beliebigen Zeitpunkt, den du über die Parameter bestimmst.
Kann mktime() negative Timestamps erzeugen?
Ja, auf 64-Bit-Systemen kannst du mit mktime() Zeitpunkte vor dem 1. Januar 1970 darstellen. mktime(0, 0, 0, 1, 1, 1960) gibt einen negativen Integer zurück. Auf 32-Bit-Systemen funktioniert das nur eingeschränkt.
Warum gibt mktime() ein anderes Ergebnis als erwartet?
Die häufigsten Ursachen sind: falsche Parameterreihenfolge (Monat und Tag vertauscht), Zeitumstellungs-Effekte oder eine unerwartete Server-Zeitzone. Prüfe zuerst date_default_timezone_get() und validiere deine Eingaben mit checkdate().
Changelog
- PHP 5.1: Aufruf ohne Parameter erzeugt eine E_STRICT-Warnung.
- PHP 8.0: Der Parameter
$is_dst wurde entfernt. Der erste Parameter $stunde ist nicht mehr optional. - Aktuell: Das Verhalten bei der Zeitumstellung ist implementierungsabhängig und kann sich zwischen PHP-Versionen leicht unterscheiden.
Fazit
Für einfache, zeitzonenunabhängige Datumsrechnungen wie den letzten Tag eines Monats oder die Berechnung eines Datums in 90 Tagen ist mktime() nach wie vor ein solides Werkzeug. Die automatische Datumskorrektur macht Kalenderberechnungen bequem, und die Funktion ist seit Jahrzehnten bewährt.
Sobald Zeitzonen, Sommerzeit oder präzise Uhrzeiten ins Spiel kommen, solltest du auf DateTimeImmutable umsteigen. Diese Klasse gibt dir volle Kontrolle über Zeitzonen, verhindert stille Korrekturen und macht deinen Code wartbarer. Für UTC-Berechnungen ohne Sommerzeit-Probleme bietet gmmktime() eine einfache Alternative, und strtotime() ist die richtige Wahl, wenn du mit Datumsstrings statt einzelnen Zahlen arbeitest.
Die Zeitumstellung ist kein Randfall. Sie trifft Anwendungen regelmäßig bei wiederkehrenden Terminen, Kalenderimporten und im Zusammenspiel mit externen Systemen. Wer das einmal erlebt hat, greift lieber gleich zu den modernen PHP-Klassen.
