Datumsfunktionen im Datenbankvergleich: PostgreSQL, MySQL, SQL Server, Oracle

1. Warum Datumsfunktionen so unterschiedlich ausfallen

Kaum ein Bereich von SQL unterscheidet sich zwischen den grossen Datenbanksystemen so stark wie Datumsfunktionen. Waehrend SELECT, JOIN und WHERE weitgehend einheitlich funktionieren, hat praktisch jedes System eigene Funktionsnamen, eigene Argumentreihenfolgen und eigene Konventionen fuer Datumsarithmetik entwickelt. Der Grund liegt darin, dass der ANSI SQL Standard Datumsoperationen nur unvollstaendig abdeckt und die meisten Datenbanken lange vor einer Standardisierung eigene, pragmatische Loesungen implementiert haben.

Das Ergebnis: Wer eine einfache Aufgabe wie "addiere 30 Tage zu diesem Datum" in PostgreSQL, MySQL, SQL Server und Oracle loesen will, braucht vier unterschiedliche Codezeilen. Diese Divergenz bei Datumsfunktionen ist einer der haeufigsten Gruende, warum Anwendungen mit Unterstuetzung fuer mehrere Datenbanken eine eigene Abstraktionsschicht fuer Datumslogik brauchen. Die folgenden Abschnitte zeigen systematisch, wie die wichtigsten Datumsfunktionen in den vier gaengigsten Systemen aussehen.

2. Aktuelles Datum und aktuelle Zeit abfragen

Selbst die einfachste Datumsfunktion, das Abfragen des aktuellen Zeitpunkts, unterscheidet sich in der Syntax zwischen den Systemen. PostgreSQL, MySQL und Oracle unterstuetzen die Standard-Funktion CURRENT_TIMESTAMP ohne Klammern, waehrend SQL Server traditionell GETDATE() bevorzugt, obwohl auch dort CURRENT_TIMESTAMP als Alias funktioniert. Fuer das reine Datum ohne Zeitanteil bietet PostgreSQL CURRENT_DATE, MySQL ebenfalls CURDATE() zusaetzlich zu CURRENT_DATE, und Oracle nutzt SYSDATE, das im Gegensatz zu den anderen Systemen sowohl Datum als auch Zeit zurueckgibt.

Ein wichtiger Unterschied bei Oracle: SYSDATE liefert die Serverzeit ohne Zeitzoneninformation, waehrend CURRENT_TIMESTAMP in Oracle die Session-Zeitzone beruecksichtigt. Wer in einer verteilten Anwendung mit mehreren Zeitzonen arbeitet, sollte in Oracle bewusst zwischen diesen beiden Funktionen unterscheiden, da eine Verwechslung zu subtilen, schwer reproduzierbaren Fehlern bei zeitkritischen Berechnungen fuehren kann.

-- PostgreSQL: standard functions, timezone-aware by default
SELECT CURRENT_TIMESTAMP, CURRENT_DATE, NOW();

-- MySQL: standard functions plus shorthand aliases
SELECT CURRENT_TIMESTAMP, CURDATE(), NOW();

-- SQL Server: GETDATE() is the traditional choice
SELECT GETDATE(), CAST(GETDATE() AS DATE), SYSDATETIME();

-- Oracle: SYSDATE has no timezone, CURRENT_TIMESTAMP respects session timezone
SELECT SYSDATE, CURRENT_TIMESTAMP FROM dual;

3. Datumsarithmetik: Tage, Monate und Jahre addieren

Bei der Datumsarithmetik zeigt sich die groesste syntaktische Vielfalt zwischen den Datenbanksystemen. PostgreSQL erlaubt die elegante Standard-nahe Schreibweise datum + INTERVAL '30 days', die direkt in Ausdruecke eingebettet werden kann. MySQL nutzt stattdessen die Funktion DATE_ADD(datum, INTERVAL 30 DAY) mit aehnlicher, aber nicht identischer Syntax. SQL Server verwendet die Funktion DATEADD(day, 30, datum) mit vertauschter Reihenfolge von Einheit und Wert im Vergleich zu MySQL. Oracle schliesslich erlaubt sowohl einfache Addition von Ganzzahlen fuer Tage (datum + 30) als auch INTERVAL-Literale fuer Monate und Jahre.

Diese Unterschiede bei Datumsfunktionen fuehren regelmaessig zu Fehlern, wenn Entwickler zwischen Projekten mit unterschiedlichen Datenbanken wechseln. Besonders tueckisch ist die Oracle-Eigenheit, dass ein einfaches datum + 30 als "30 Tage addieren" interpretiert wird, waehrend in PostgreSQL dieselbe Schreibweise ohne INTERVAL-Angabe einen Typfehler erzeugt, weil PostgreSQL Ganzzahl-Addition auf ein Datum nicht implizit als Tagesarithmetik interpretiert.

-- PostgreSQL: INTERVAL literal, embeddable in expressions
SELECT order_date + INTERVAL '30 days' AS due_date FROM orders;
SELECT order_date + INTERVAL '3 months' AS renewal_date FROM orders;

-- MySQL: DATE_ADD function with INTERVAL keyword
SELECT DATE_ADD(order_date, INTERVAL 30 DAY) AS due_date FROM orders;
SELECT DATE_ADD(order_date, INTERVAL 3 MONTH) AS renewal_date FROM orders;

-- SQL Server: DATEADD with swapped unit/value order
SELECT DATEADD(day, 30, order_date) AS due_date FROM orders;
SELECT DATEADD(month, 3, order_date) AS renewal_date FROM orders;

-- Oracle: plain integer addition for days, INTERVAL for months/years
SELECT order_date + 30 AS due_date FROM orders;
SELECT ADD_MONTHS(order_date, 3) AS renewal_date FROM orders;

4. Differenzen zwischen zwei Zeitpunkten berechnen

Die Berechnung der Differenz zwischen zwei Zeitstempeln ist eine weitere Aufgabe, bei der Datumsfunktionen erheblich divergieren. PostgreSQL liefert bei der Subtraktion zweier TIMESTAMP-Werte direkt ein INTERVAL-Ergebnis, das Tage, Stunden und Minuten kombiniert darstellt. MySQL bietet mit TIMESTAMPDIFF(unit, start, end) eine explizite Funktion, die die Differenz in einer gewaehlten Einheit zurueckgibt. SQL Server nutzt DATEDIFF(unit, start, end) mit aehnlicher Signatur, aber anderem Funktionsnamen.

Oracle behandelt die Subtraktion zweier DATE-Werte als reine Fliesskommazahl in Tagen, was fuer Entwickler aus anderen Systemen zunaechst ungewohnt ist, aber praktisch ist, sobald man das Verhalten kennt. Fuer Differenzen in anderen Einheiten als Tagen bietet Oracle zusaetzlich EXTRACT in Kombination mit Intervall-Subtraktion bei TIMESTAMP-Werten. Wer Datumsdifferenzen datenbankuebergreifend berechnet, sollte immer explizit die gewuenschte Zieleinheit (Tage, Stunden, Minuten) im Code dokumentieren, weil die impliziten Rueckgabewerte zwischen den Systemen stark variieren.

-- PostgreSQL: subtraction returns an INTERVAL
SELECT shipped_at - ordered_at AS delivery_duration FROM orders;
SELECT EXTRACT(DAY FROM shipped_at - ordered_at) AS delivery_days FROM orders;

-- MySQL: explicit function with chosen unit
SELECT TIMESTAMPDIFF(DAY, ordered_at, shipped_at) AS delivery_days FROM orders;
SELECT TIMESTAMPDIFF(HOUR, ordered_at, shipped_at) AS delivery_hours FROM orders;

-- SQL Server: DATEDIFF with unit as first argument
SELECT DATEDIFF(day, ordered_at, shipped_at) AS delivery_days FROM orders;

-- Oracle: subtraction returns a plain number of days
SELECT shipped_at - ordered_at AS delivery_days FROM orders;

5. Einzelne Datumsteile extrahieren

Fuer das Extrahieren einzelner Bestandteile eines Datums, etwa Jahr, Monat, Wochentag oder Kalenderwoche, bietet PostgreSQL die Standard-nahe Funktion EXTRACT(field FROM datum), die auch von MySQL und Oracle unterstuetzt wird. Das macht EXTRACT zu einer der wenigen wirklich portablen Datumsfunktionen zwischen den Systemen. SQL Server unterstuetzt EXTRACT erst seit neueren Versionen vollstaendig und nutzt traditionell die Funktion DATEPART(unit, datum), die funktional aequivalent ist, aber eine andere Syntax hat.

Bei der Kalenderwoche zeigen sich zusaetzliche Feinheiten: PostgreSQL folgt standardmaessig der ISO-8601-Definition, bei der die Woche am Montag beginnt und die erste Woche des Jahres mindestens vier Tage im neuen Jahr enthalten muss. MySQL bietet mit dem zweiten Parameter der Funktion WEEK(datum, mode) verschiedene Modi, die unterschiedliche Wochendefinitionen abbilden, und SQL Server haengt die Interpretation der Kalenderwoche von der Server-Einstellung DATEFIRST ab. Diese Unterschiede bei Datumsfunktionen fuer Kalenderwochen sind ein haeufiger Grund fuer abweichende Reporting-Zahlen zwischen Systemen.

-- PostgreSQL, MySQL, Oracle: EXTRACT works nearly identically
SELECT EXTRACT(YEAR FROM order_date) AS order_year,
       EXTRACT(MONTH FROM order_date) AS order_month,
       EXTRACT(ISODOW FROM order_date) AS weekday
FROM orders;

-- SQL Server: DATEPART with unit as first argument
SELECT DATEPART(year, order_date) AS order_year,
       DATEPART(month, order_date) AS order_month,
       DATEPART(weekday, order_date) AS weekday
FROM orders;

6. Datumsformatierung fuer Ausgabe und Vergleich

Formatierung von Datumswerten fuer die Anzeige ist ein weiterer Bereich mit stark abweichenden Datumsfunktionen. PostgreSQL nutzt TO_CHAR(datum, 'YYYY-MM-DD') mit einer Formatierungssprache, die Oracle sehr aehnlich ist, weil beide Systeme historisch verwandte Formatierungskonventionen verwenden. MySQL bietet DATE_FORMAT(datum, '%Y-%m-%d') mit einer komplett anderen Formatierungssprache, die auf Prozentzeichen-Platzhalter statt auf Buchstabenmuster setzt. SQL Server nutzt FORMAT(datum, 'yyyy-MM-dd') mit .NET-basierten Formatstrings, die wiederum einer dritten Konvention folgen.

Diese drei unterschiedlichen Formatierungssprachen (Oracle-Stil, MySQL-Stil, .NET-Stil) machen die Formatierung von Datumswerten zu einer der am wenigsten portablen Aufgaben in SQL. In der Praxis empfiehlt es sich, Formatierung fuer die Anzeige generell in der Anwendungsschicht vorzunehmen und der Datenbank nur ISO-8601-konforme TIMESTAMP-Werte zu entnehmen, statt Formatierungslogik in SQL-Abfragen zu verstreuen, die bei einem Datenbankwechsel komplett neu geschrieben werden muesste.

-- PostgreSQL: Oracle-style format tokens
SELECT TO_CHAR(order_date, 'YYYY-MM-DD') AS formatted_date FROM orders;

-- MySQL: percent-sign placeholders
SELECT DATE_FORMAT(order_date, '%Y-%m-%d') AS formatted_date FROM orders;

-- SQL Server: .NET-style format string
SELECT FORMAT(order_date, 'yyyy-MM-dd') AS formatted_date FROM orders;

-- Oracle: same format tokens as PostgreSQL
SELECT TO_CHAR(order_date, 'YYYY-MM-DD') AS formatted_date FROM orders;

7. Zeitzonenbehandlung: die groesste Fehlerquelle

Zeitzonenbehandlung ist der Bereich der Datumsfunktionen, der die meisten Produktionsfehler verursacht. PostgreSQL unterscheidet strikt zwischen TIMESTAMP (ohne Zeitzone) und TIMESTAMPTZ (mit Zeitzone), wobei TIMESTAMPTZ intern immer in UTC gespeichert und bei der Ausgabe in die Session-Zeitzone konvertiert wird. Diese klare Trennung verhindert viele typische Zeitzonenfehler, erfordert aber, dass Entwickler bewusst den richtigen Typ waehlen.

MySQL bietet mit TIMESTAMP einen Typ, der intern ebenfalls in UTC gespeichert wird und bei Lese- und Schreibzugriffen in die Session-Zeitzone konvertiert, waehrend DATETIME keine Zeitzonenkonvertierung durchfuehrt und den Wert exakt so speichert, wie er eingegeben wurde. SQL Server kennt seit Version 2008 den Typ DATETIMEOFFSET, der den UTC-Offset explizit mitspeichert, waehrend DATETIME2 zeitzonenlos bleibt. Oracle bietet mit TIMESTAMP WITH TIME ZONE und TIMESTAMP WITH LOCAL TIME ZONE zwei unterschiedliche Varianten, die sich in der Speicherung des Offsets unterscheiden. Wer Zeitzonenfehler vermeiden will, sollte konsequent zeitzonenbewusste Typen fuer alle Zeitstempel nutzen, die ueber Systemgrenzen hinweg Bedeutung haben, wie etwa Bestellzeitpunkte in international taetigen Shops.

8. Datumslogik portabel in der Anwendung halten

Angesichts der erheblichen Unterschiede bei Datumsfunktionen zwischen den grossen Datenbanksystemen lohnt sich eine bewusste Architekturentscheidung: Komplexe Datumsarithmetik, die ueber einfache Vergleiche hinausgeht, sollte entweder vollstaendig in der Anwendungsschicht (etwa mit einer Datums-Bibliothek wie Carbon in PHP oder date-fns in JavaScript) oder hinter einer klar definierten Datenbank-Abstraktionsschicht gekapselt werden. Rohes SQL mit datenbankspezifischen Datumsfunktionen direkt in der Geschaeftslogik zu verstreuen, macht jede spaetere Migration erheblich teurer.

Ein pragmatischer Mittelweg: Einfache Vergleiche und Filter (WHERE order_date >= '2026-01-01') funktionieren in allen vier Systemen nahezu identisch und lassen sich problemlos in SQL belassen. Komplexere Berechnungen wie Geschaeftstage-Arithmetik, wiederkehrende Termine oder Kalenderwochen-Aggregationen profitieren dagegen von einer zentralen Implementierung ausserhalb der Datenbank, wo die Logik einmal getestet und fuer alle Zieldatenbanken konsistent angewendet werden kann.

9. Datumsfunktionen im direkten Vergleich

Die folgende Tabelle stellt die wichtigsten Datumsfunktionen der vier Systeme fuer typische Aufgaben gegenueber.

Diese Gegenueberstellung zeigt, warum eine 1:1-Uebersetzung von Datumslogik zwischen Systemen ohne Tests riskant ist. Kleine Unterschiede in Rundungsverhalten, Wochendefinition oder Zeitzonenkonvertierung fallen oft erst bei Randfaellen auf, etwa an Monatsgrenzen, Schaltjahren oder beim Wechsel zwischen Sommer- und Winterzeit.

10. Zusammenfassung

Datumsfunktionen gehoeren zu den Bereichen von SQL, in denen die Datenbanksysteme am wenigsten miteinander uebereinstimmen. Von der Abfrage des aktuellen Zeitpunkts ueber Datumsarithmetik und Formatierung bis zur Zeitzonenbehandlung nutzt jedes System eigene Funktionsnamen, eigene Argumentreihenfolgen und teilweise sogar unterschiedliche implizite Verhaltensweisen bei identischer Aufgabenstellung. Wer diese Unterschiede kennt, vermeidet die haeufigsten Fehlerquellen bei Migrationen und bei Anwendungen, die mehrere Datenbanken unterstuetzen.

Die wichtigste praktische Konsequenz: Datumslogik, die ueber einfache Vergleiche hinausgeht, gehoert idealerweise in eine zentrale Anwendungsschicht statt direkt in datenbankspezifisches SQL. So bleibt die komplexeste und fehleranfaelligste Logik an einer Stelle testbar, waehrend die Datenbank selbst nur fuer einfache, weitgehend portable Datumsvergleiche zustaendig bleibt.

11. FAQ: Datumsfunktionen im Datenbankvergleich