Zeitzonen unter Linux korrekt verwalten: timedatectl und tzdata

1. Warum die Zeitzonenkonfiguration mehr ist als Kosmetik

Die Zeitzone eines Servers wirkt wie eine reine Anzeigefrage, entscheidet in Wirklichkeit aber darueber, wie Zeitstempel in Logs, Datenbanken und Backups interpretiert werden. Steht ein Server auf Europe/Berlin, wird die Sommerzeitumstellung automatisch beruecksichtigt, was zur Folge hat, dass sich der Abstand zwischen zwei aufeinanderfolgenden Tagen zweimal im Jahr um eine Stunde verschiebt. Fuer Menschen, die einen Log direkt lesen, ist das komfortabel, fuer Systeme, die Zeitraeume berechnen oder Ereignisse ueber mehrere Server hinweg vergleichen, wird es zur Fehlerquelle.

Besonders kritisch wird die Zeitzonenverwaltung, wenn mehrere Server in unterschiedlichen Regionen betrieben werden, etwa ein Webserver in Frankfurt und eine Datenbank in Amsterdam. Ohne einheitliche Konvention entsteht schnell Verwirrung darueber, ob ein Zeitstempel bereits umgerechnet wurde oder nicht. Die uebliche Antwort der meisten erfahrenen Administratoren lautet, Server konsequent auf UTC zu betreiben und die Umrechnung in lokale Zeit ausschliesslich in der Anwendungsschicht vorzunehmen, dort, wo ein Mensch die Zeit tatsaechlich lesen muss.

2. Wie tzdata Zeitzonenregeln speichert

Die Datenbank tzdata, auch als IANA Time Zone Database oder Olson-Datenbank bekannt, enthaelt fuer jede Region der Welt die historischen und aktuellen Regeln fuer Zeitzonen und Sommerzeitumstellungen. Jede Regel wird als kompilierte Binaerdatei unter /usr/share/zoneinfo/ abgelegt, etwa /usr/share/zoneinfo/Europe/Berlin. Diese Dateien enthalten nicht nur den aktuellen UTC-Offset, sondern auch alle historischen Umstellungstermine, was es ermoeglicht, auch fuer vergangene Daten die damals gueltige Zeitzone korrekt zu berechnen.

Die Benennung nach Regionen statt nach festen Abkuerzungen wie CET oder CEST ist bewusst gewaehlt. Waehrend eine Abkuerzung nicht zwischen Winter- und Sommerzeit unterscheiden kann, kapselt eine Regionsbezeichnung wie Europe/Berlin automatisch alle Umstellungsregeln, die fuer diese politische Region gelten. Aendert ein Land seine Zeitzonenregeln, etwa durch einen Parlamentsbeschluss, wird ausschliesslich das tzdata-Paket aktualisiert, ohne dass eine einzige Anwendung angepasst werden muss.

3. timedatectl: Zeitzone anzeigen und setzen

Auf allen systemd-basierten Distributionen ist timedatectl das zentrale Werkzeug, um die aktuelle Zeitzone anzuzeigen und zu aendern. Der Befehl ohne Argumente zeigt lokale Zeit, UTC-Zeit, die aktuell gesetzte Zeitzone und den Synchronisationsstatus der Systemuhr in einer uebersichtlichen Zusammenfassung. Die Liste aller verfuegbaren Zeitzonen liefert timedatectl list-timezones, gefiltert nach Region etwa mit timedatectl list-timezones | grep Europe.

Das Setzen einer neuen Zeitzone erfolgt mit timedatectl set-timezone Europe/Berlin und wirkt sofort, ohne dass ein Neustart des Systems erforderlich ist. Intern setzt timedatectl lediglich einen symbolischen Link von /etc/localtime auf die entsprechende Datei unter /usr/share/zoneinfo/, ein Mechanismus, der auch manuell nachvollzogen werden kann. Wichtig: Bereits laufende Prozesse, die die Zeitzone bereits eingelesen haben, etwa lange laufende Datenbank-Server, uebernehmen die neue Zeitzone unter Umstaenden erst nach einem Neustart des jeweiligen Prozesses.

# Show current time, timezone, and sync status
timedatectl

# List all available time zones
timedatectl list-timezones

# Filter for a specific region
timedatectl list-timezones | grep -i Europe

# Set the system timezone
sudo timedatectl set-timezone Europe/Berlin

# Verify the change was applied
timedatectl show --property=Timezone

4. UTC versus lokale Zeitzone auf Servern

Die weit verbreitete Empfehlung, Server auf UTC zu betreiben, hat einen konkreten technischen Grund: UTC kennt keine Sommerzeitumstellung und keine doppelten oder fehlenden Stunden. Bei der Umstellung von Sommer- auf Winterzeit existiert in lokaler Zeit eine Stunde zweimal, bei der Umstellung von Winter- auf Sommerzeit fehlt eine Stunde komplett. Ein Cronjob, der taeglich um 02:30 Uhr laeuft, kann in der Umstellungsnacht entweder zweimal oder gar nicht ausgefuehrt werden, ein Verhalten, das in UTC-Zeit schlicht nicht auftritt.

Die pragmatische Loesung fuer die meisten Deployments: Die Serverzeitzone bleibt auf UTC gesetzt, waehrend die Anzeige fuer Endnutzer in der jeweiligen Anwendungsschicht erfolgt, etwa durch PHP mit DateTimeZone oder durch JavaScript im Browser des Nutzers. Dadurch bleiben alle internen Zeitstempel in Logs, Datenbanken und Backups eindeutig und ohne Umstellungsluecken, waehrend die Anzeige fuer Menschen weiterhin korrekt lokalisiert erfolgt. Nur Systeme, bei denen ein Mensch direkt auf der Konsole arbeitet und lokale Zeit erwartet, profitieren tatsaechlich von einer lokalen Zeitzone auf Betriebssystemebene.

5. Sommerzeit-Fallstricke bei Anwendungen und Cronjobs

Neben dem klassischen Cronjob-Problem tritt bei Anwendungen mit lokaler Zeitzone haeufig ein subtilerer Fehler auf: Zeitstempel werden gespeichert, ohne die Zeitzone selbst mitzuspeichern, und spaeter falsch interpretiert. Ein Datenbank-Feld vom Typ DATETIME ohne Zeitzoneninformation speichert nur eine nackte Uhrzeit, ohne festzulegen, ob es sich um lokale Zeit oder UTC handelt. Wird die Serverzeitzone spaeter geaendert, etwa bei einem Umzug in ein anderes Rechenzentrum, aendert sich die Interpretation aller historischen Zeitstempel schlagartig, ohne dass ein einziges Byte in der Datenbank veraendert wurde.

Ein weiterer haeufiger Fehler betrifft Log-Rotation und Backup-Skripte, die von einer konstanten Anzahl Stunden zwischen zwei Laeufen ausgehen. Ein Skript, das ueber date -d "24 hours ago" arbeitet, liefert in der Umstellungsnacht ein um eine Stunde verschobenes Ergebnis, wenn die Systemzeitzone lokal gesetzt ist. Mit einer konsequenten UTC-Konfiguration auf Betriebssystemebene und expliziter Zeitzonenangabe in jedem Datenbankfeld, das Zeitstempel speichert, lassen sich beide Fehlerklassen von vornherein ausschliessen.

6. tzdata-Updates einspielen und pruefen

Zeitzonenregeln aendern sich haeufiger als vermutet, weil einzelne Laender ihre Sommerzeitregelungen oder sogar ihre gesamte Zeitzone per Gesetz aendern koennen. Das tzdata-Paket wird deshalb regelmaessig ueber den normalen Paketmanager aktualisiert, unabhaengig vom restlichen Systemupdate. Auf Debian-basierten Systemen reicht apt install --only-upgrade tzdata, um ausschliesslich diese eine Datenbank auf den neuesten Stand zu bringen, ohne ein vollstaendiges Systemupdate anzustossen.

Nach einem Update sollte geprueft werden, ob bereits laufende Prozesse die neuen Regeln uebernommen haben. Viele Laufzeitumgebungen wie die JVM oder aeltere PHP-Versionen cachen Zeitzoneninformationen beim Start und benoetigen einen Neustart, um Aenderungen an tzdata zu uebernehmen. Ein einfacher Test ist date -d "2026-10-25 02:30 Europe/Berlin" vor und nach dem Update zu vergleichen, um sicherzustellen, dass die Umstellungsregel korrekt im System hinterlegt ist.

# Update only the tzdata package on Debian/Ubuntu
sudo apt update && sudo apt install --only-upgrade -y tzdata

# Update tzdata on RHEL/Rocky/AlmaLinux
sudo dnf update -y tzdata

# Check the currently installed tzdata version
dpkg -l tzdata | tail -n 1

# Test a specific transition date after the update
date -d "2026-10-25 02:30 Europe/Berlin"

# Reconfigure the system timezone package interactively (Debian)
sudo dpkg-reconfigure tzdata

7. Zeitzonen in Anwendungen: PHP, Datenbanken, Docker

In PHP-Anwendungen sollte die Zeitzone niemals implizit von der Systemeinstellung uebernommen werden, sondern explizit ueber date.timezone in der php.ini oder programmatisch ueber date_default_timezone_set() gesetzt werden. Fehlt diese Einstellung, greift PHP auf die Systemzeitzone zurueck, was bei einem spaeteren Serverumzug zu stillschweigend geaenderten Zeitangaben in der gesamten Anwendung fuehrt, ohne dass der Anwendungscode selbst veraendert wurde.

MySQL und MariaDB speichern TIMESTAMP-Spalten intern immer in UTC und rechnen bei jeder Abfrage automatisch in die Sitzungszeitzone um, waehrend DATETIME-Spalten die eingegebene Zeit ohne jede Umrechnung speichern. Diese Unterscheidung ist entscheidend fuer die Wahl des richtigen Spaltentyps. In Docker-Containern wiederum wird die Zeitzone standardmaessig auf UTC gesetzt, unabhaengig von der Zeitzone des Docker-Hosts, was in den meisten Faellen genau das gewuenschte Verhalten ist und nur bei expliziten Anforderungen an lokale Zeitanzeige ueber ein gemountetes /etc/localtime ueberschrieben werden sollte.

8. Zeitzone bei der Server-Provisionierung automatisieren

Bei automatisierter Provisionierung mit Cloud-Init, Ansible oder aehnlichen Werkzeugen sollte die Zeitzone explizit als Teil des Standard-Images definiert werden, statt sich auf Distributions-Defaults zu verlassen, die sich zwischen Cloud-Anbietern und Basis-Images erheblich unterscheiden koennen. Ein Cloud-Init-Snippet mit der Direktive timezone: UTC stellt sicher, dass jede neu provisionierte Instanz von Anfang an konsistent konfiguriert ist, unabhaengig davon, in welcher Cloud-Region sie gestartet wird.

Fuer bestehende Infrastruktur empfiehlt sich ein automatisierter Compliance-Check, der regelmaessig ueber alle Server hinweg prueft, ob timedatectl show --property=Timezone den erwarteten Wert zurueckgibt, und bei Abweichungen einen Alarm ausloest. Gerade in gewachsenen Infrastrukturen mit Servern aus unterschiedlichen Provisionierungsepochen ist eine uneinheitliche Zeitzonenkonfiguration eine der haeufigsten, aber am leichtesten behebbaren Ursachen fuer verwirrende Zeitstempel in zentralisierten Log-Systemen.

9. Zeitzonen-Werkzeuge im Vergleich

Fuer die Verwaltung von Zeitzonen unter Linux existieren mehrere Werkzeuge mit unterschiedlichem Funktionsumfang. Die folgende Tabelle stellt die gaengigsten Ansaetze gegenueber.

Der klare Trend geht zu explizit gesetzten, per Werkzeug validierten Konfigurationen statt manuell verwalteter Symlinks. Wer timedatectl konsequent in Provisionierungsskripten einsetzt, vermeidet die klassischen Tippfehler bei manuell gesetzten Symlinks und erhaelt zusaetzlich eine sofortige Bestaetigung, ob die Zeitzone tatsaechlich wie erwartet gesetzt wurde.

10. Zusammenfassung

Die korrekte Verwaltung von Zeitzonen unter Linux ist keine kosmetische Einstellung, sondern beeinflusst direkt, wie Zeitstempel in Logs, Datenbanken und Cronjobs interpretiert werden. timedatectl ist das zentrale Werkzeug fuer systemd-basierte Distributionen, um die aktuelle Zeitzone anzuzeigen, zu setzen und den Synchronisationsstatus zu pruefen, waehrend tzdata die zugrunde liegende Regeldatenbank liefert und regelmaessig unabhaengig vom restlichen System aktualisiert werden sollte.

Fuer Server empfiehlt sich konsequent UTC als Betriebssystem-Zeitzone, weil UTC keine Sommerzeitumstellung kennt und damit doppelte oder fehlende Stunden bei Cronjobs von vornherein ausschliesst. Die Umrechnung in lokale Zeit gehoert in die Anwendungsschicht, dort, wo tatsaechlich ein Mensch die Zeit lesen muss. Wer diese Trennung konsequent einhaelt und tzdata-Updates regelmaessig einspielt, vermeidet die haeufigsten Fehlerquellen rund um Zeitzonen im Serverbetrieb.

11. FAQ: Zeitzonen unter Linux