Ein Datum liegt selten in der Form vor, in der man es braucht. Aus einem Formularfeld kommt Text, aus einem Logfile ein Zeitstempel in fremdem Format, aus einer Schnittstelle ein ISO-String. PHP bringt für diese Umwandlung eine Funktion mit, die erstaunlich viel versteht, von 2026-03-06 bis next Friday. Dieses Tutorial zeigt, was sie leistet, wo sie zuverlässig arbeitet und an welchen Stellen sie in deutschsprachigen Projekten regelmäßig für Fehler sorgt.
Was macht PHP strtotime()?
Wer in PHP mit Datumsangaben aus Formularen, Logfiles oder APIs arbeitet, stösst früher oder später auf die Frage, wie aus einem Text wie "2026-03-06 14:30:00" ein berechenbarer Wert wird. Genau hier setzt PHP strtotime an: Die Funktion liest einen englischsprachigen Datumsstring und liefert einen Unix-Timestamp zurück, also die Zahl der Sekunden seit dem 1. Januar 1970. Mit diesem Output lässt sich das Datum dann sortieren, vergleichen oder weiterverarbeiten.

Bevor die Syntax und die typischen Stolperfallen folgen, ein Blick auf die beachtliche Bandbreite an Formaten, die diese Funktion versteht.
Der Charme von strtotime() liegt in der Vielfalt der erkannten Formate. Neben dem ISO-8601-Format wie "2026-03-06" versteht die Funktion auch Ausdrücke wie "next Friday", "+1 week" oder "first day of next month". Diese Flexibilität macht sie zum Schweizer Taschenmesser für einfache Datumskonvertierungen, birgt aber auch typische Stolperfallen, die in diesem Tutorial Schritt für Schritt aufgelöst werden.
Syntax und Rückgabewert von strtotime()
Die Signatur ist kurz und gut zu merken. PHP strtotime() erwartet einen Datumsstring und akzeptiert optional einen zweiten Parameter, der als Referenzpunkt für relative Berechnungen dient.
<?php
strtotime(string $datetime, ?int $baseTimestamp = null): int|false
Der Rückgabewert ist entweder ein gültiger Unix-Timestamp als Integer oder der Wert false, wenn der String nicht interpretierbar ist. Wichtig: Die Funktion wirft keine Exception, sondern signalisiert Fehler ausschliesslich über den Rückgabewert. Ein erstes Beispiel zeigt das Zusammenspiel mit der eingebauten PHP-Funktion date(), die den Timestamp wieder in eine lesbare Form bringt.
<?php
$timestamp = strtotime('2026-03-06 14:30:00');
echo date('d.m.Y H:i', $timestamp);
/* Ausgabe: 06.03.2026 14:30 */
Absolute Datumsangaben sicher parsen
Absolute Datumsangaben sind solche, die ein konkretes Datum benennen, ohne sich auf ein anderes zu beziehen. Das ISO-Format YYYY-MM-DD funktioniert mit PHP strtotime() zuverlässig, ebenso die englische Schreibweise mit ausgeschriebenem Monatsnamen.
<?php
$ts1 = strtotime('2026-03-06');
$ts2 = strtotime('March 6, 2026');
$ts3 = strtotime('6 March 2026 14:30 UTC');
echo date('Y-m-d H:i', $ts1) . "\n";
echo date('Y-m-d H:i', $ts2) . "\n";
echo date('Y-m-d H:i', $ts3) . "\n";
/* Alle drei liefern denselben Tag */
Wer mit reinen Datumsstrings arbeitet, sollte die Komponenten Jahr, Monat und Tag in dieser Reihenfolge angeben. Dann ist die Zuordnung eindeutig und unabhängig von der lokalen Spracheinstellung des Servers. Im nächsten Schritt geht es um die deutlich mächtigere Variante: relative Datumsangaben.
Relative Datumsangaben mit PHP strtotime()
Relative Angaben beschreiben Zeitpunkte in Bezug auf einen Bezugspunkt. Standardmäßig ist dieser Bezugspunkt der aktuelle Zeitpunkt. Die folgenden Schlüsselwörter sind besonders häufig im Einsatz.
<?php
echo date('Y-m-d', strtotime('now')) . "\n";
/* heute */
echo date('Y-m-d', strtotime('+1 week')) . "\n";
/* in einer Woche */
echo date('Y-m-d', strtotime('next Friday')) . "\n";
/* naechster Freitag */
echo date('Y-m-d', strtotime('first day of next month')) . "\n";
/* erster Tag des Folgemonats */
echo date('Y-m-d', strtotime('last Friday of December 2026')) . "\n";
/* letzter Freitag im Dezember 2026 */
Diese Syntax ist sehr ausdrucksstark und ersetzt in vielen Fällen umständliche Berechnungen. Trotzdem lohnt es sich, die Ergebnisse beim ersten Einsatz mit var_dump() zu prüfen, denn manche Konstruktionen liefern auf den ersten Blick verwirrende Werte. So springt strtotime('+1 month') am 31. Januar nicht auf den 28. Februar, sondern auf den 3. März, weil PHP intern Monat plus eins rechnet und dann das Datum normalisiert.
Hilfreich ist auch der Unterschied zwischen next Friday und Friday. Die Variante next Friday springt zuverlässig auf den nächsten Freitag in der Folgewoche, selbst wenn heute Freitag ist. Ein nacktes Friday hingegen meint den nächsten Freitag ab heute, wobei der heutige Tag ausgeschlossen ist. Wer Termine für "diese Woche Freitag" sucht, sollte daher den expliziten Wochentag mit Datum kombinieren oder mit DateTimeImmutable::modify() arbeiten. Wer mit Wochenenden, Feiertagen oder Werktagen rechnet, kommt mit den eingebauten Schlüsselwörtern allein nicht weit und sollte solche Logik in eine eigene kleine Helper-Klasse auslagern.
Die häufigste Stolperfalle: deutsche Datumsformate
PHP strtotime() ist auf englischsprachige Eingaben optimiert. Genau hier liegt die wohl häufigste Quelle für Bugs in deutschen Projekten. Ein String wie "06.03.2026" wird unter Umständen gar nicht oder falsch interpretiert. Das Slash-Format "06/03/2026" wertet PHP strtotime() als amerikanisches mm/dd/yyyy aus, also als 3. Juni 2026 statt als 6. März 2026.
<?php
/* Punkt-Notation: oft unzuverlaessig */
$ts = strtotime('06.03.2026');
var_dump($ts);
/* Ergebnis kann je nach Eingabe und PHP-Version variieren */
/* Sichere Loesung: Format explizit angeben */
$dt = DateTime::createFromFormat('d.m.Y', '06.03.2026');
if ($dt !== false) {
echo $dt->format('Y-m-d');
/* Ausgabe: 2026-03-06 */
}
Sobald ein Datumsstring direkt aus einem deutschen Eingabefeld stammt, ist DateTime::createFromFormat() oder die alternative Schreibweise date_create_from_format() aus dem DateTime-Tutorial die bessere Wahl. Diese Funktionen erwarten ein konkretes Format und scheitern sauber, wenn die Eingabe nicht passt. PHP strtotime() bleibt dann für Fälle reserviert, in denen das Eingabeformat klar englischsprachig ist.
Fehler sicher erkennen
Da strtotime() bei ungültigen Eingaben false zurückgibt, liegt es nahe, mit einer kurzen Prüfung zu reagieren. Vorsicht ist allerdings beim Operator ! geboten, weil der Timestamp 0 (also der 1. Januar 1970) als falsy gilt und fälschlich als Fehler interpretiert würde.
<?php
$eingabe = 'irgendwas Bloedes';
$timestamp = strtotime($eingabe);
if ($timestamp === false) {
echo 'Ungueltiger Datumsstring';
} else {
echo 'Timestamp: ' . $timestamp;
}
/* Achtung: if (!$timestamp) wuerde auch 0 als Fehler werten */
Mit dem strikten Vergleich === false wird der Sonderfall sauber abgefangen. Diese Prüfung gehört in jeden Code, der externe Eingaben verarbeitet, etwa aus Formularen, CSV-Dateien oder API-Antworten. Praktisch ist auch eine kleine Wrapper-Funktion, die einen Default-Timestamp zurückgibt oder eine Exception wirft, je nachdem, wie streng die Anwendung mit ungültigen Daten umgehen soll.
Der zweite Parameter $baseTimestamp
Der zweite Parameter macht PHP strtotime() besonders interessant für Berechnungen, die nicht ab "jetzt" laufen sollen, sondern ab einem festen Bezugsdatum. Typischer Anwendungsfall: Mahnungslauf, Lieferzeitberechnung, Zahlungsfrist.
<?php
$lieferdatum = strtotime('2026-03-06');
$mahnung = strtotime('+14 days', $lieferdatum);
echo 'Lieferdatum: ' . date('d.m.Y', $lieferdatum) . "\n";
echo 'Mahnung am: ' . date('d.m.Y', $mahnung) . "\n";
/* Lieferdatum: 06.03.2026
Mahnung am: 20.03.2026 */
Ohne den zweiten Parameter würde strtotime('+14 days') immer 14 Tage ab dem heutigen Tag berechnen. Sobald ein konkretes Bezugsdatum vorliegt, sollte dieses unbedingt explizit übergeben werden, damit die Logik unabhängig vom Aufrufzeitpunkt ist und sich auch in Tests reproduzierbar verhält. In Unit-Tests ist das ein wichtiger Punkt: Nur mit einem festen $baseTimestamp lassen sich Datumsregeln so prüfen, dass die Tests morgen, nächste Woche und im nächsten Quartal noch das gleiche Ergebnis liefern.
Zeitzonen und Sommerzeit beachten
PHP strtotime() arbeitet mit der Zeitzone, die über date_default_timezone_set() oder die php.ini-Direktive date.timezone gesetzt ist. Beim Wechsel zwischen Sommer- und Winterzeit kann das zu unerwarteten Stundensprüngen führen, weil eine Stunde des Tages gar nicht oder doppelt existiert.
<?php
date_default_timezone_set('Europe/Berlin');
$ts = strtotime('2026-03-29 02:30:00');
echo date('Y-m-d H:i T', $ts);
/* Am DST-Uebergang verschiebt sich die Anzeige */
Für kritische Berechnungen mit internationalen Nutzern ist es daher sinnvoll, auf die objektorientierte Variante mit DateTime und DateTimeImmutable plus explizitem DateTimeZone umzusteigen. PHP strtotime() bleibt nützlich für schnelle Konvertierungen, sollte aber nicht das Werkzeug der Wahl für Buchungssysteme oder Schichtpläne sein.
Der folgende Ablauf fasst zusammen, welchen Weg ein Datumsstring durch die Funktion nimmt.
flowchart TD
A[Datumsstring uebergeben] --> B{Format erkannt?}
B -->|Ja| C[Unix-Timestamp berechnen]
B -->|Nein| D[false zurueckgeben]
C --> E[mit date weiterverarbeiten]
D --> F["Pruefung mit === false"]
mktime als alternativer Konstruktor
Wer einen Timestamp aus einzelnen Komponenten wie Jahr, Monat und Tag baut, hat mit mktime() eine Alternative zu PHP strtotime(). Die Funktion erwartet die einzelnen Werte als Integer und liefert direkt den passenden Unix-Timestamp zurück. Das ist immer dann praktisch, wenn die Bestandteile bereits getrennt vorliegen, etwa aus drei <select>-Feldern eines Formulars oder aus einem Datenbank-Result.
<?php
/* mktime(stunde, minute, sekunde, monat, tag, jahr) */
$ts = mktime(14, 30, 0, 3, 6, 2026);
echo date('Y-m-d H:i', $ts);
/* 2026-03-06 14:30 */
/* gleiches Ergebnis ueber strtotime und einen String */
echo date('Y-m-d H:i', strtotime('2026-03-06 14:30'));
Faustregel: PHP strtotime() ist die richtige Wahl, wenn das Datum als String vorliegt. mktime() passt besser, wenn die Komponenten als Zahlen aus einer anderen Quelle kommen, weil dann kein Zwischen-Stringbau nötig ist. Für das Prüfen, ob ein Datum überhaupt existiert (Stichwort 30. Februar), ergaenzt sich checkdate() als Validator, bevor mktime() aufgerufen wird.
Daten des letzten Monats berechnen
Eine der häufigsten Fragen rund um Reports lautet: "Wie bekomme ich den ersten und letzten Tag des vergangenen Monats?". Mit relativen strtotime-Ausdrücken ist das ein Zweizeiler.
<?php
$von = date('Y-m-d', strtotime('first day of last month'));
$bis = date('Y-m-d', strtotime('last day of last month'));
echo "Auswertung von $von bis $bis";
/* z.B. Auswertung von 2026-04-01 bis 2026-04-30 */
first day of und last day of sind feste Schlüsselwörter, die PHP strtotime() in Kombination mit relativen Monatsangaben sicher interpretiert. Sie umgehen die berüchtigte 31-Januar-plus-1-Monat-Falle aus dem Abschnitt zu relativen Daten, weil sie immer auf den tatsächlichen Monatsanfang oder das tatsächliche Monatsende springen, unabhängig davon, wie viele Tage der Folgemonat hat. Für die letzten 7 oder 30 Tage dagegen passt strtotime('-7 days') direkt, weil hier keine Monatsgrenze relevant ist.
Das 2038-Problem auf 32-Bit-Systemen
Unix-Timestamps sind in vielen 32-Bit-Systemen als signed Integer gespeichert. Der grösste darstellbare Wert entspricht dem 19. Januar 2038. Auf solchen Servern liefert strtotime('2040-01-01') ein false zurück oder einen falsch interpretierten Wert irgendwo um das Jahr 1970. Auf 64-Bit-Systemen, was heute der Standard ist, reicht der Bereich locker bis ins Jahr 292 Milliarden und das Problem ist praktisch irrelevant.
<?php
echo PHP_INT_SIZE;
/* 8 = 64-Bit, 4 = 32-Bit */
if (PHP_INT_SIZE === 4) {
echo 'Achtung: 32-Bit-System, Daten ab 2038 sind unsicher.';
}
Wer auf altem Shared Hosting mit 32-Bit-PHP arbeitet oder Logfiles aus solchen Systemen importiert, sollte frühe Warnsignale (false als Rückgabewert bei plausiblen Datumsstrings) ernst nehmen und auf 64-Bit-PHP upgraden. Alternativ stellt DateTimeImmutable Daten ohne diese Grenze dar, weil sie intern mit Strings arbeiten.
strtotime() vs DateTime und date_create()
Im Code großer PHP-Projekte tauchen drei verwandte Wege auf, um aus einem String ein Datum zu machen. PHP strtotime() liefert einen Integer-Timestamp und ist sehr knapp im Aufruf. Die Funktion date_create() erzeugt ein DateTime-Objekt und ist damit die prozedurale Schwester von new DateTime(). Beide DateTime-Varianten bieten reichhaltige Methoden für Modifikationen, Differenzen und Formatierungen.
Eine grobe Faustregel: PHP strtotime() ist die richtige Wahl, wenn nur ein Timestamp gebraucht wird, wenn das Eingabeformat sicher englischsprachig ist und wenn die Berechnung nicht über DST-Wechsel hinweg laufen muss. Sobald Modifikationen, Differenzen oder Zeitzonen ins Spiel kommen, sind DateTimeImmutable plus passende Format-Parser die robustere Lösung.
Ein weiterer Punkt für den Umstieg ist die Lesbarkeit im Team. Methodenketten wie (new DateTimeImmutable('2026-03-06'))->modify('+1 week')->format('d.m.Y') machen sofort klar, was passiert. Eine knappe Konstruktion wie date('d.m.Y', strtotime('+1 week', strtotime('2026-03-06'))) ist zwar kürzer, wirkt im Code-Review aber häufiger fragwürdig. Im Pull Request gewinnt fast immer die ausdrucksstarke Variante, weil sie weniger Erklärung benötigt und weniger Folgefragen produziert.
Ein letzter Hinweis für fortgeschrittene Nutzer: Wer mit großen Datenmengen arbeitet, etwa beim Import von tausenden Logzeilen, profitiert von der Performance der Funktion. Sie ist deutlich schneller als der Umweg über ein vollständiges DateTime-Objekt, weil sie intern direkt einen Integer-Wert berechnet. Bei reinen Konvertierungs-Schleifen, in denen ohnehin nur ein Timestamp gespeichert wird, lohnt sich also der schlankere Aufruf.
Fazit
PHP strtotime() ist eine ungewöhnlich vielseitige Funktion, die schnelle Datumsumwandlungen mit wenigen Zeichen erlaubt. Wer ihre Spielregeln kennt, parst englische Datumsstrings, relative Angaben und Bezugsdaten in Sekundenbruchteilen. Wichtig bleibt das Bewusstsein für die typischen Fallen: deutsche Punkt- oder Slash-Notation, falsy-Trick mit dem Wert 0 und Stundensprünge bei DST-Wechseln. Wer diese Punkte berücksichtigt und bei kritischen Anwendungen auf DateTimeImmutable wechselt, hat mit PHP strtotime() ein zuverlässiges Werkzeug für den Alltag im PHP-Backend.