Wie konfiguriere ich Zeitzonen korrekt in PostgreSQL?
- Einleitung
- Systemzeitzone und PostgreSQL
- Zeitzone temporär in einer Session setzen
- Zeitzone dauerhaft in der Konfigurationsdatei festlegen
- Verfügbare Zeitzonen finden
- Tipp zur Verwendung von Zeitzonen in der Praxis
- Zeitzonen bei Datentypen berücksichtigen
- Zusammenfassung
Einleitung
Die korrekte Konfiguration der Zeitzone in PostgreSQL ist essenziell, um sicherzustellen, dass Datums- und Zeitwerte korrekt interpretiert und gespeichert werden. PostgreSQL arbeitet intern mit Zeitzonen, um Zeitangaben konsistent zu verwalten, besonders wenn mehrere Anwendungen oder Benutzer aus verschiedenen Zeitzonen Daten schreiben oder lesen.
Systemzeitzone und PostgreSQL
PostgreSQL verwendet standardmäßig die Zeitzone des Betriebssystems, auf dem es läuft. Diese Einstellung bestimmt, wie Zeiten ohne explizite Zeitzone interpretiert werden. Um die aktuelle Konfiguration der Zeitzone in PostgreSQL zu prüfen, kann man die SQL-Abfrage SHOW timezone; ausführen. Das Ergebnis gibt die momentan verwendete Zeitzone zurück, etwa Europe/Berlin oder UTC.
Zeitzone temporär in einer Session setzen
Man kann die Zeitzone auch pro Datenbank-Sitzung verändern. Dazu wird der Befehl SET timezone = Zeitzone; verwendet, wobei Zeitzone ein gültiger Zeitzonenname oder eine Offset-Angabe ist, z.B. Europe/Berlin oder +02. Diese Änderung gilt nur für die aktuelle Verbindung, nach dem Trennen der Session wird die Standardeinstellung wieder verwendet.
Zeitzone dauerhaft in der Konfigurationsdatei festlegen
Um die Zeitzone dauerhaft für alle Verbindungen und Datenbank-Sitzungen festzulegen, kann man die Datei postgresql.conf bearbeiten und den Parameter timezone anpassen. Zum Beispiel:
timezone = Europe/BerlinNach Änderung der Konfigurationsdatei muss der PostgreSQL-Dienst neu gestartet werden, damit die Einstellung wirksam wird. Alternativ kann man die Konfiguration mit pg_ctl reload oder durch Senden eines HUP-Signals neu laden, wenn dies unterstützt wird. Beachten Sie, dass der Reload nicht bei allen Parametern ausreicht, ein voller Neustart notwendig sein kann.
Verfügbare Zeitzonen finden
PostgreSQL unterstützt eine Vielzahl von Zeitzonen, die auf der IANA Time Zone Database (tzdata) basieren. Man kann die verfügbaren Zeitzonen in der Datenbank mit der Abfrage SELECT * FROM pg_timezone_names; anzeigen lassen. Dort findet man sowohl bekannte Ortsnamen als auch numerische Offsets. Es ist empfehlenswert, bevorzugt Ortsnamen wie Europe/Berlin zu verwenden, da diese automatisch Sommerzeit und andere lokale Änderungen berücksichtigen.
Tipp zur Verwendung von Zeitzonen in der Praxis
In vielen Anwendungen ist es ratsam, die Datenbank intern auf UTC-Zeit zu stellen und zeitbezogene Werte nur bei der Ein- und Ausgabe in die lokale Zeitzone umzuwandeln. Dies vermeidet Probleme durch Sommerzeitwechsel oder unterschiedliche Zeitzonen in verschiedenen Systemkomponenten. Beispielsweise wird in postgresql.conf dann timezone = UTC verwendet, und in der Anwendung erfolgt die Umrechnung.
Zeitzonen bei Datentypen berücksichtigen
PostgreSQL unterscheidet zwischen den Datentypen timestamp with time zone (kurz timestamptz) und timestamp without time zone. Der Typ timestamptz speichert intern UTC-Werte und wandelt bei der Ausgabe die Zeit basierend auf der Sitzungseinstellungen in die richtige Zeitzone um. Der Typ timestamp without time zone hingegen speichert einfach einen Zeitwert ohne Zeitzoneninformationen. Für zeitkritische Anwendungen und globale Systeme wird empfohlen, timestamptz zu verwenden.
Zusammenfassung
Die Zeitzonenkonfiguration in PostgreSQL erfolgt standardmäßig systemweit, kann aber sowohl dauerhaft über die postgresql.conf-Datei als auch temporär in einer Sitzung mit SET timezone = angepasst werden. Für beste Kompatibilität und korrekte Handhabung von Sommerzeit und globalen Zeitunterschieden empfiehlt sich die Verwendung von Zeitzonen in Form von Ortsnamen und bevorzugt der Datentyp timestamp with time zone. Zudem hilft es oft, intern UTC zu verwenden und Umrechnungen in der Applikation vorzunehmen.
