Errori tipici quando si lavora con date e orari

Oggi parliamo ancora di errori. Perché lavorare con date e orari è come camminare su un campo minato: tutto va bene finché non fai il primo passo sbagliato.

Errori nella scelta del tipo di dato

Qui spesso inizia il disastro. Scegliere il tipo di dato sbagliato può mandare all’aria tutti i tuoi sforzi con date e orari.

Situzione 1: Uso di DATE invece di TIMESTAMP

Quando registri un evento che ha non solo la data ma anche l’orario, usare solo DATE ti fa perdere informazioni importanti.

CREATE TABLE orders (
    order_id SERIAL PRIMARY KEY,
    order_date DATE -- solo data
);

Con questo design non puoi sapere se due ordini sono stati fatti la mattina o la sera. Perché mai perdere l’occasione di bere un caffè e guardare dei bei timestamp?

Situzione 2: Dimenticarsi dei fusi orari

Se la tua app lavora con utenti internazionali ma salvi data e ora solo con TIMESTAMP, senza considerare i fusi orari, i tuoi dati diventano “senza casa”. TIMESTAMPTZ risolve questo problema per te.

CREATE TABLE events (
    event_time TIMESTAMP -- senza fuso orario
);

Nessuno vuole confondere un evento serale a New York con uno mattutino a Tokyo. Usa TIMESTAMPTZ!

Errori nell’uso delle funzioni

Situzione 1: Formato sbagliato in TO_CHAR()

I problemi iniziano se specifichi il formato in modo errato. Per esempio:

SELECT TO_CHAR(NOW(), 'YYYY-DD-MM'); -- Ops, mese e giorno invertiti

Qui invece del solito anno-mese-giorno, ottieni anno-giorno-mese. Questo può portare a situazioni comiche (ma non sempre piacevoli) per i tuoi utenti. Controlla sempre il formato.

Situzione 2: Errori con TO_DATE()

Al contrario, se provi a convertire una stringa in data ma il formato non corrisponde, PostgreSQL ti dà errore.

SELECT TO_DATE('10/31/2023', 'YYYY-MM-DD'); -- Errore! Il formato non corrisponde.

Il formato della stringa deve corrispondere esattamente a quello che hai indicato. Per esempio:

SELECT TO_DATE('2023-10-31', 'YYYY-MM-DD'); -- Tutto ok.

Errori con gli intervalli temporali

Situzione 1: Conversione implicita dei tipi

A volte ti dimentichi delle particolarità della conversione dei tipi. Per esempio:

SELECT NOW() + '1'; -- ERRORE! Non è chiaro cosa sia '1'.

PostgreSQL non capisce che vuoi aggiungere un giorno. Il modo giusto:

SELECT NOW() + INTERVAL '1 day';

Situzione 2: Confusione con la sottrazione degli intervalli

Fai attenzione quando aggiungi o sottrai intervalli:

SELECT NOW() - INTERVAL '-1 day'; -- Questo aggiunge un giorno invece di sottrarre!

Qui il doppio meno fa l’effetto opposto. Meglio evitare queste costruzioni.

Errori di arrotondamento e troncamento dei dati

Situzione 1: Troncamento sbagliato con DATE_TRUNC()

Quando usi DATE_TRUNC() per raggruppare i dati, controlla sempre di aver scelto il livello giusto. Per esempio:

SELECT DATE_TRUNC('hour', NOW()); -- Tronca all’inizio dell’ora
SELECT DATE_TRUNC('minute', NOW()); -- Tronca all’inizio del minuto

Se ti aspettavi un risultato e ne hai ottenuto un altro, forse hai scelto il livello sbagliato.

Situzione 2: Dimenticarsi dei fusi orari con DATE_TRUNC()

Se lavori con orari in diversi fusi orari, il risultato può essere inaspettato:

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

Assicurati che il fuso orario sia specificato correttamente, altrimenti rischi di perderti nel tempo (letteralmente).

Unix time: secondi persi

Unix time (EPOCH) è comodo ma insidioso. L’errore più comune è confondere secondi e millisecondi.

SELECT TO_TIMESTAMP(1680000000); -- Giusto (secondi).
SELECT TO_TIMESTAMP(1680000000000); -- Errore! Troppi zeri.

Controlla in cosa è misurato il tuo timestamp, così non salvi milioni di secondi in più.

Errori con i fusi orari

Situzione 1: Fusi orari confusi

Quando lavori con utenti di diversi fusi orari, i dati possono mescolarsi. Per esempio:

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

Assicurati di sapere esattamente in quale fuso orario sono i dati.

Situzione 2: Duplicazione dei fusi orari

Salvare data e ora e poi provare a considerare di nuovo i fusi orari è una cattiva idea:

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

Questo può portare a calcoli sbagliati.

Consigli per evitare errori

Scegli il tipo di dato giusto. Se lavori con dati temporali internazionali, usa TIMESTAMPTZ. Se ti basta solo la data, vai di DATE.

Testa le tue query. Assicurati che i risultati siano quelli che ti aspetti, soprattutto se lavori con intervalli temporali, formati o arrotondamenti.

Salva i dati temporali in UTC. È il modo migliore per evitare confusione con i fusi orari.

Controlla i formati. Assicurati che il formato in TO_CHAR() e TO_DATE() corrisponda ai tuoi dati.

Usa le funzioni con attenzione. Leggi bene la documentazione di PostgreSQL sulle funzioni temporali per evitare sorprese.

Lavorare con dati temporali può essere complicato, ma con il giusto approccio e attenzione ai dettagli tutto fila liscio. Date e orari sono una parte importante delle tue app, e dimenticarsene è pericoloso quanto dimenticare di mettere la sveglia il lunedì mattina!