Typische Fehler beim Umgang mit Daten und Zeit

Heute reden wir mal wieder über Fehler. Denn mit Daten und Zeit zu arbeiten ist wie ein Minenfeld: Alles läuft gut, bis du den ersten falschen Schritt machst.

Fehler bei der Wahl des Datentyps

Hier fängt oft das ganze Drama an. Wenn du den falschen Datentyp auswählst, kannst du dir die ganze Arbeit mit Daten und Zeit kaputtmachen.

Situation 1: Verwendung von DATE statt TIMESTAMP

Wenn du ein Ereignis speicherst, das nicht nur ein Datum, sondern auch eine Uhrzeit hat, verlierst du mit DATE wichtige Infos.

CREATE TABLE orders (
    order_id SERIAL PRIMARY KEY,
    order_date DATE -- nur Datum
);

Mit so einem Design kannst du nicht rausfinden, ob zwei Bestellungen morgens oder abends gemacht wurden. Warum solltest du dir die Chance nehmen, gemütlich Kaffee zu trinken und auf schöne Zeitstempel zu schauen?

Situation 2: Zeitzonen vergessen

Wenn deine App international genutzt wird, du aber Datum und Zeit nur mit TIMESTAMP ohne Zeitzone speicherst, werden deine Daten quasi "obdachlos". TIMESTAMPTZ löst das für dich.

CREATE TABLE events (
    event_time TIMESTAMP -- ohne Zeitzone
);

Niemand will ein Abend-Event in New York mit einem Morgen-Event in Tokio verwechseln. Nutze TIMESTAMPTZ!

Fehler bei der Nutzung von Funktionen

Situation 1: Falsches Format in TO_CHAR()

Die Probleme gehen los, wenn du das Format falsch angibst. Zum Beispiel:

SELECT TO_CHAR(NOW(), 'YYYY-DD-MM'); -- Ups, Monat und Tag vertauscht

Hier hast du statt dem gewohnten Jahr-Monat-Tag ein Jahr-Tag-Monat bekommen. Das kann zu lustigen (aber nicht immer angenehmen) Situationen für deine User führen. Check das Format immer doppelt.

Situation 2: Fehler bei TO_DATE()

Andersrum: Wenn du einen String ins Datum umwandeln willst, das Format aber nicht passt, gibt dir PostgreSQL einen Fehler aus.

SELECT TO_DATE('10/31/2023', 'YYYY-MM-DD'); -- Fehler! Format passt nicht.

Das Format vom String muss genau dem entsprechen, was du angibst. Zum Beispiel:

SELECT TO_DATE('2023-10-31', 'YYYY-MM-DD'); -- Alles korrekt.

Fehler mit Zeitintervallen

Situation 1: Implizite Typumwandlung vergessen

Manchmal vergisst du die Besonderheiten bei der Typumwandlung. Zum Beispiel:

SELECT NOW() + '1'; -- FEHLER! Was soll '1' sein?

PostgreSQL weiß nicht, dass du einen Tag addieren willst. Richtig wäre:

SELECT NOW() + INTERVAL '1 day';

Situation 2: Verwirrung beim Subtrahieren von Intervallen

Sei vorsichtig beim Addieren oder Subtrahieren von Intervallen:

SELECT NOW() - INTERVAL '-1 day'; -- Das addiert einen Tag statt zu subtrahieren!

Hier macht das doppelte Minus das Gegenteil. Solche Konstrukte lieber vermeiden.

Fehler beim Runden und Abschneiden von Daten

Situation 1: Falsches Abschneiden mit DATE_TRUNC()

Wenn du DATE_TRUNC() zum Gruppieren nutzt, check immer, ob du wirklich das richtige Level gewählt hast. Zum Beispiel:

SELECT DATE_TRUNC('hour', NOW()); -- Schneidet auf Stundenanfang ab
SELECT DATE_TRUNC('minute', NOW()); -- Schneidet auf Minutenanfang ab

Wenn du ein anderes Ergebnis erwartet hast, hast du vielleicht das falsche Level gewählt.

Situation 2: Zeitzonen vergessen bei DATE_TRUNC()

Wenn du mit Zeiten in verschiedenen Zeitzonen arbeitest, kann das Ergebnis überraschend sein:

SELECT DATE_TRUNC('day', NOW() AT TIME ZONE 'UTC');

Check, dass die Zeitzone stimmt, sonst verlierst du dich in der Zeit (im wahrsten Sinne).

Unix-Zeit: verlorene Sekunden

Unix-Zeit (EPOCH) ist praktisch, aber tricky. Der häufigste Fehler: Verwechslung von Sekunden und Millisekunden.

SELECT TO_TIMESTAMP(1680000000); -- Das ist korrekt (Sekunden).
SELECT TO_TIMESTAMP(1680000000000); -- Fehler! Zu viele Nullen.

Check, in welcher Einheit dein Timestamp ist, damit du nicht Millionen unnötiger Sekunden speicherst.

Fehler mit Zeitzonen

Situation 1: Verwirrende Zeitzonen

Wenn du mit Usern aus verschiedenen Zeitzonen arbeitest, können die Daten durcheinandergeraten. Zum Beispiel:

SELECT TIMESTAMP '2023-10-01 10:00:00' AT TIME ZONE 'UTC';

Stell sicher, dass du genau weißt, in welcher Zeitzone deine Daten sind.

Situation 2: Zeitzonen doppelt berücksichtigen

Ein Datum mit Zeit speichern und dann nochmal die Zeitzone draufpacken – schlechte Idee:

SELECT TIMESTAMP '2023-10-01 10:00:00 UTC' AT TIME ZONE 'UTC'; -- Mach das nicht!

Das führt zu falschen Berechnungen.

Tipps zur Fehlervermeidung

Wähle den passenden Datentyp. Wenn du mit internationalen Zeitdaten arbeitest, nimm TIMESTAMPTZ. Wenn nur das Datum reicht, bleib bei DATE.

Teste deine Queries. Check, ob die Ergebnisse passen, besonders bei Intervallen, Formaten oder Rundungen.

Speichere Zeitdaten in UTC. Das ist der beste Weg, um Zeitzonen-Chaos zu vermeiden.

Check die Formate. Achte darauf, dass das Format in TO_CHAR() und TO_DATE() zu deinen Daten passt.

Sei vorsichtig mit Funktionen. Lies dir die PostgreSQL Doku zu Zeitfunktionen genau durch, damit du keine bösen Überraschungen erlebst.

Mit Zeitdaten zu arbeiten ist nicht immer easy, aber mit dem richtigen Mindset und etwas Aufmerksamkeit läuft alles ziemlich smooth. Daten und Zeit sind ein wichtiger Teil deiner Apps – sie zu vergessen ist so riskant, wie den Wecker am Montagmorgen nicht zu stellen!