Wenn Sie in einem multinationalen Umfeld arbeiten, ist es sehr wahrscheinlich, dass Sie mit verschiedenen Zeitzonen und mit Servern bzw. Datenbanken zu tun haben, die sich in verschiedenen Zeitzonen befinden. Wenn es um Zeitzonen geht, gibt es jedoch leider einige Unterschiede zwischen unserem SQL Server, Oracle und PostgreSQL — sowohl bei den beteiligten Datentypen als auch bei der Art und Weise, wie das Datum/die Uhrzeit abgerufen wird.
In diesem Artikel werden wir die diversen Unterschiede zwischen den Zeitzonen von SQL Server, Oracle und PostgreSQL sowie die verschiedenen Datentypen von Datum und Uhrzeit besprechen sowie den korrekten Weg zum Einstellen und Ändern der Instanz-Zeitzone betrachten.
Zunächst eine Übersicht über die Datentypen mit Zeitzone die in den 3 RDBMS verfügbar sind:
In SQL Server, Oracle und PostgreSQL kann die tatsächliche Datumszeit mit der Datumsfunktion GETDATE( )
abgerufen werden. Um die Zeitzone zu erhalten, müssen wir jedoch wie folgt vorgehen:
SELECT SYSDATETIMEOFFSET()
Diese Funktion gibt das aktuelle Datum und die Uhrzeit sowie den Zeitzonen zurück.
In SQL Server Version 2019 wurde die Funktion CURRENT_TIMEZONE( )
eingeführt, die den Wert der Zeitzone zurückgibt:
SELECT CURRENT_TIMEZONE()
Bitte beachten Sie, dass das gleiche Ergebnis in früheren Versionen von SQL Server mit der folgenden Abfrage erzielt werden kann:
DECLARE @TimeZone VARCHAR(50)
EXEC MASTER.dbo.xp_regread 'HKEY_LOCAL_MACHINE','SYSTEM\CurrentControlSet\Control\TimeZoneInformation','TimeZoneKeyName',@TimeZone OUT
SELECT @TimeZone as TimeZone
Wie Sie sehen, kann die Zeitzone direkt vom Host-Server abgerufen werden.
Bei Oracle sind die Dinge etwas komplizierter. Zunächst einmal ist die Funktion DBTIMEZONE
zu verwenden, um die Zeitzone der Instanz zu ermitteln:
SELECT DBTIMEZONE FROM dual;
Wenn ich auf derselben Instanz SYSTIMESTAMP
verwende, wird der Zeitstempel mit der Zeitzone des Systems zurückgegeben:
SELECT systimestamp FROM dual;
Ein anderes Ergebnis erhalten wir, wenn wir die Funktion SYSDATE
verwenden:
SELECT to_char(sysdate, 'dd.mm.yyyy hh:mi:ss') FROM dual;
Der Grund für diese Ergebnisse ist, dass alle diese Funktionen das Datum/die Uhrzeit direkt vom System, d. h. vom Host-Server, abrufen, genau wie wir es bei SQL Server gesehen haben. Datum/Uhrzeit und Zeitzone werden auf Betriebssystemebene auf dem Host-Server festgelegt, unabhängig davon, was auf Ebene der Datenbankinstanz eingestellt ist.
In Oracle haben wir die Möglichkeit, die lokale Zeitzone der Sitzung mit der Funktion SESSIONTIMEZONE( )
anzuzeigen:
SELECT sessiontimezone FROM dual;
Mit PostgreSQL haben wir eine andere Funktion - oder um korrekt zu sein, wir haben mehr als eine Funktion, alle nach ANSI SQL Standard. Zum Beispiel können wir das aktuelle Datum und die Uhrzeit mit CURRENT_TIMESTAMP( )
zurückgeben:
SELECT current_timestamp;
Und wir können die Zeitzone der Instanz überprüfen, indem wir die Einstellungen des PostgreSQL-Clusters abfragen (denken Sie an die unterschiedliche Namenskonvention für PostgreSQL).
SELECT name, setting FROM pg_settings WHERE name='TimeZone';
Das Gleiche kann auch folgend erreicht werden:
show timezone;
Wie bei Oracle kann die Sitzung eine andere Zeitzone haben als der PostgreSQL-Cluster, aber dazu später mehr.
Als professioneller SQL Server Support und zertifizierter Microsoft Partner unterstützen wir Sie in allen Fragen und individuellen Problemen rund um Ihre Serverumgebung, egal ob vor Ort oder remote. Überzeugen Sie sich selbst von unserem vielfältigen Angebot und den individuellen Leistungspaketen.
Sehen wir uns nun an, wie wir die Zeitzoneneinstellungen ändern können und wie wir unsere Datumszeit in einer anderen Zeitzone, als der Standardzeitzone des Systems erhalten können.
In SQL Server wird die Datumszeit (und Zeitzone) wie bereits angedeutet, direkt vom Betriebssystem des Host-Servers abgeleitet, sodass es unmöglich ist, sie nur für die Instanz zu ändern. Um die Zeitzone von SQL Server zu ändern, müssen Sie sie auf der Ebene des Betriebssystems ändern, indem Sie die Datumszeit des Servers ändern.
Wenn dies jedoch nicht möglich ist, gibt es ab SQL Server 2016 die Möglichkeit, die Funktion AT TIME ZONE
zu verwenden, die eine Datumszeit in die angegebene Zeitzone umwandelt. Sehen wir uns ein Beispiel an:
Lassen Sie sich zunächst alle im System verfügbaren Zeitzonen auflisten: sys.time_zone_info
SELECT * FROM sys.time_zone_info
Überprüfen Sie also noch einmal unsere aktuelle Datumszeit und Zeitzone:
SELECT SYSDATETIMEOFFSET()
In unserem Beispiel würden wir sie gerne in "Pacific Standard Time" umrechnen:
SELECT SYSDATETIMEOFFSET() AT TIME ZONE 'Pacific Standard Time';
Bitte beachten Sie, dass die Funktion das Eingabedatum mit der Information der Datumszeitverschiebung benötigt, sonst kann sie die Zeitzonenumrechnung nicht durchführen.
Auch in Oracle wird, wie bereits oben erläutert, die Datumszeit auf der Ebene des Betriebssystems abgerufen. Um die Zeitzone zu ändern, muss sie also auf dem Host-Server geändert werden. Nichtsdestotrotz ist es in Oracle möglich, die Zeitzone der Datenbank zu ändern. Allerdings ist die Zeitzone der Datenbank nur für die Datentypen TIMESTAMP WITH LOCAL TIME ZONE
relevant.
Lassen Sie uns also zunächst die Liste der verfügbaren Zeitzonen im System abrufen:
SELECT tzname, tzabbrev FROM V$TIMEZONE_NAMES;
Dann ändern wir die Zeitzone der Datenbank in die gleiche, die wir auf dem SQL Server verwendet haben. Die Änderung kann auf Session- oder auf DB-Ebene erfolgen. Zunächst auf DB-Ebene.
Leider ist der Name hier in Oracle anders, da er America/Los_Angeles oder abgekürzt PST lautet:
ALTER DATABASE SET time_zone = 'America/Los_Angeles'; -- DB-weit, erfordert Neustart
Wenn wir das überprüfen, können wir diese Änderung sehen:
SELECT DBTIMEZONE FROM dual;
Aber wenn wir diese Anfrage ausführen:
SELECT current_timestamp FROM dual;
Wir erhalten wieder die gleichen Ergebnisse wie zuvor: Das liegt daran, dass CURRENT_TIMESTAMP
auf Sitzungsebene abgefragt wird.
Aber wie bereits angedeutet, können wir in Oracle mit der Anweisung ALTER SESSION
eine andere Zeitzone auch auf Sitzungsebene einrichten:
ALTER SESSION SET time_zone = 'America/Los_Angeles';
Überprüfen wir es:
SELECT current_timestamp FROM dual;
In PostgreSQL können wir stattdessen die Zeitzone der Datenbank unabhängig vom System einstellen. Zuerst werden wir eine Liste der verfügbaren Zeitzonen abfragen:
SELECT name, abbrev FROM pg_timezone_names;
Wie bei SQL Server und Oracle wollen wir also die Datenbank auf die Zeitzone der pazifischen Küste der USA einstellen. Hier haben wir einen anderen Namen:
ALTER SYSTEM set TimeZone='America/Los_Angeles';
An diesem Punkt müssen wir PostgreSQL neu starten oder die Konfiguration mit diesem Befehl neu laden:
SELECT pg_reload_conf();
Wir können nun die aktualisierte Zeit überprüfen:
SELECT current_timestamp;
Überprüfen Sie auch die Zeitzone:
show timezone;
Wenn wir die Datumszeit des Servers überprüfen, können wir nun sehen, dass sie immer noch in UTC ist:
Wie in Oracle haben wir die Möglichkeit, die Zeitzone auf Sitzungsebene zu ändern, indem wir einen einfachen SET TIMEZONE-
Befehl eingeben:
SET TimeZone = 'Europe/Berlin';
Wir können das jetzt überprüfen:
SELECT current_timestamp;
Natürlich gehen alle Änderungen, die auf Sitzungsebene vorgenommen wurden verloren, sobald die Sitzung getrennt wird. Sowohl in Oracle als auch in PostgreSQL.
In diesem Tipp haben wir gesehen, dass in SQL Server und Oracle die Zeitzone durch die am häufigsten verwendeten Datums- und Zeitfunktionen auf der Ebene des Hostservers festgelegt und übernommen wird. PostgreSQL kann eine andere Zeitzone als der Host haben und das ist die Datumszeit, die von allen Funktionen abgerufen wird.
Sowohl Oracle als auch PostgreSQL haben die Möglichkeit, eine andere Zeitzone auf der Sitzungsebene einzustellen und SQL Server kann eine Datumszeit in einer anderen Zeitzone zurückgeben.
Zu guter Letzt haben wir gesehen, wie man die Liste der in den 3 Datenbanksystemen verfügbaren Zeitzonen-Bezeichnungen abruft und dass sie sich alle voneinander unterscheiden.
Trotz allem sind die verschiedenen Zeitzonen nicht starr und Änderungen können jederzeit erfolgen. Diese werden - zumindest bei Oracle - im Rahmen von Updates nicht automatisch berücksichtigt, so dass ggf. neue “zone files” installiert werden müssen. Das wohl bekannteste Beispiel: West Samoa wechselte am 30.12.2011 von UTC - 10 nach UTC + 13.
Die Mainzer Datenfabrik verfügt über Expert:innen auf diesem Gebiet. Gerne helfen wir Ihnen bei Fragen und Problemen zur Änderung von Zeitzonen in verschiedenen Umgebungen weiter. Kontaktieren Sie uns dafür gerne über unser Kontaktformular und evaluieren Sie gemeinsam mit uns Ihren Bedarf. Wir freuen uns von Ihnen zu hören!
Kontaktieren Sie uns gerne über das
Kontaktformular und vereinbaren ein unverbindliches
Beratungsgespräch mit unseren Berater:innen zur
Bedarfsevaluierung. Gemeinsam optimieren wir Ihre
Umgebung und steigern Ihre Performance!
Wir freuen uns auf Ihre Kontaktaufnahme!