Antwort

In SQL gibt es eine große Menge an Funktionen zur Arbeit mit Daten und Intervallen: DATEDIFF, DATEADD (T-SQL), die Arbeit mit dem Typ INTERVAL (PostgreSQL), Funktionalität für die Zeitzonenumstellung (AT TIME ZONE). Für die korrekte Arbeit mit Daten ist wichtig, Datentypen mit Berücksichtigung der Zeitzone zu verwenden (TIMESTAMP WITH TIME ZONE, timestamptz) und nicht einfach DATE oder DATETIME, besonders für globale Dienste.

In verschiedenen DBMS variieren Syntax und Arbeitsweisen:

SQL Server: DATEDIFF, DATEADD, FORMAT, aber kein vollständiges INTERVAL. Zeitzonen werden explizit geregelt.
PostgreSQL: Unterstützung für INTERVAL, zahlreiche Funktionen (+/- INTERVAL), direkte Steuerung der Zeitzonen.

Fehler treten häufig aufgrund der Inkonsistenz der Speicherung in UTC/lokaler Zeit und der Vermischung von Operationen auf, die den Unterschied nicht berücksichtigen.

Beispiel für die Berechnung des Unterschieds (PostgreSQL)

SELECT
  EXTRACT(EPOCH FROM (event_end AT TIME ZONE 'UTC' - event_start AT TIME ZONE 'UTC')) / 3600 AS hours
FROM events

Fangfrage

Kann die Zeitdifferenz in DATEDIFF eine negative Zahl ergeben, und was bedeutet ihre Reihenfolge?

Antwort: Ja, DATEDIFF (DATEDIFF(day, d1, d2)) gibt eine negative Zahl zurück, wenn d2 < d1. Es ist wichtig, die Parameterreihenfolge nicht zu verwechseln: Zuerst kommt die Maßeinheit, dann das Startdatum und dann das Enddatum.

Beispiel:

SELECT DATEDIFF(day, '2024-05-01', '2024-04-25') -- gibt -6 zurück

Beispiele aus der Praxis

Geschichte

In einem Projekt mit globalen Nutzern wurden Berichte nach der lokalen Zeit der Server in jeder Region erstellt. Das Ergebnis — auseinanderfallende Aggregationen nach Daten und das Auftreten von "Löchern" an der Tagesgrenze für Nutzer aus anderen Zeitzonen. Behebt wurde dies durch die Umstellung aller Zeitdaten auf UTC und die Neuberechnung nur zur Anzeige.

Geschichte

Bei der Berechnung der Dauer eines Abonnements durch DATEDIFF wurde die Reihenfolge der Daten verwechselt. Infolgedessen wurden einige Nutzer fälschlicherweise als "Supernutzer" mit eindeutig negativem Alter eingestuft. Behebt wurde dies durch die Einführung einer Überprüfung der Datumsreihenfolge.

Geschichte

Der Entwickler speicherte DATETIME ohne Berücksichtigung der Zeitzone; bei der Migration zu PostgreSQL wurden die Werte als UTC interpretiert, obwohl sie ursprünglich in GMT+3 waren, was zu einer Verschiebung der Ereignisse in den Berichten um 3 Stunden nach hinten führte. Fazit — immer Daten mit Berücksichtigung der Zone speichern und umwandeln!