Erreurs typiques lors du travail avec les dates et l'heure

Aujourd'hui, on va encore causer d'erreurs. Parce que bosser avec les dates et l'heure, c'est un peu comme marcher sur un champ de mines : tout roule jusqu'à ce que tu fasses un pas de travers.

Erreurs dans le choix du type de données

C'est souvent là que les galères commencent. Un mauvais choix de type de données peut ruiner tous tes efforts pour gérer les dates et l'heure.

Situation 1 : Utiliser DATE au lieu de TIMESTAMP

Quand tu veux enregistrer un événement qui a non seulement une date mais aussi une heure, utiliser juste DATE peut te faire perdre des infos importantes.

CREATE TABLE orders (
    order_id SERIAL PRIMARY KEY,
    order_date DATE -- juste la date
);

Avec ce design, tu ne sauras pas si deux commandes ont été passées le matin ou le soir. Pourquoi se priver du plaisir de boire un café en matant de belles timestamps ?

Situation 2 : Oubli des fuseaux horaires

Si ton appli gère des utilisateurs internationaux mais que tu sauvegardes la date et l'heure juste avec TIMESTAMP, sans gérer les fuseaux horaires, tes données risquent de devenir "sans-abri". TIMESTAMPTZ règle ce souci pour toi.

CREATE TABLE events (
    event_time TIMESTAMP -- sans fuseau horaire
);

Personne n'a envie de confondre un event du soir à New York avec un event du matin à Tokyo. Utilise TIMESTAMPTZ !

Erreurs dans l'utilisation des fonctions

Situation 1 : Mauvais format dans TO_CHAR()

Les problèmes commencent si tu te plantes dans le format. Par exemple :

SELECT TO_CHAR(NOW(), 'YYYY-DD-MM'); -- Oups, j'ai inversé le mois et le jour

Ici, au lieu du classique année-mois-jour, on a eu année-jour-mois. Ça peut donner des situations marrantes (mais pas toujours cool) pour tes users. Vérifie toujours le format.

Situation 2 : Erreurs avec TO_DATE()

À l'inverse, si tu veux convertir une string en date mais que le format ne colle pas, PostgreSQL va te sortir une erreur.

SELECT TO_DATE('10/31/2023', 'YYYY-MM-DD'); -- Erreur ! Format incorrect.

Le format de la string doit coller pile à ce que t'as mis. Par exemple :

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

Erreurs avec les intervalles de temps

Situation 1 : Conversion implicite foireuse

Parfois tu peux zapper les subtilités de la conversion de types. Genre :

SELECT NOW() + '1'; -- ERREUR ! C'est quoi ce '1' ?

PostgreSQL pige pas que tu veux ajouter un jour. La bonne façon :

SELECT NOW() + INTERVAL '1 day';

Situation 2 : Confusion avec la soustraction d'intervalles

Fais gaffe quand tu ajoutes ou retires des intervalles :

SELECT NOW() - INTERVAL '-1 day'; -- Ça ajoute un jour au lieu d'en retirer !

Ici, le double moins fait l'effet inverse. Évite ce genre de trucs.

Erreurs d'arrondi et de découpage des données

Situation 1 : Mauvais découpage avec DATE_TRUNC()

Quand tu utilises DATE_TRUNC() pour grouper des données, vérifie toujours que t'as bien choisi le bon niveau. Par exemple :

SELECT DATE_TRUNC('hour', NOW()); -- Coupe au début de l'heure
SELECT DATE_TRUNC('minute', NOW()); -- Coupe au début de la minute

Si tu t'attendais à un résultat et que t'en as eu un autre, t'as peut-être pas pris le bon niveau.

Situation 2 : Oublier les fuseaux horaires avec DATE_TRUNC()

Si tu bosses avec des heures dans différents fuseaux, le résultat peut surprendre :

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

Assure-toi que le fuseau horaire est bien mis, sinon tu risques de te perdre dans le temps (littéralement).

Unix time : les secondes perdues

L'Unix time (EPOCH) — c'est pratique, mais piégeux. L'erreur la plus courante, c'est de confondre secondes et millisecondes.

SELECT TO_TIMESTAMP(1680000000); -- C'est bon (secondes).
SELECT TO_TIMESTAMP(1680000000000); -- Erreur ! Trop de zéros.

Vérifie dans quoi est mesuré ton timestamp, histoire de pas stocker un million de secondes en trop.

Erreurs avec les fuseaux horaires

Situation 1 : Fuseaux horaires embrouillés

Quand tu bosses avec des users de plusieurs fuseaux, les données peuvent se mélanger. Genre :

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

Sois sûr de bien piger dans quel fuseau sont tes données.

Situation 2 : Duplication des fuseaux horaires

Enregistrer une date avec l'heure puis essayer de remettre un fuseau horaire par-dessus — mauvaise idée :

SELECT TIMESTAMP '2023-10-01 10:00:00 UTC' AT TIME ZONE 'UTC'; -- Fais pas ça !

Ça peut donner des calculs complètement faux.

Conseils pour éviter les erreurs

Choisis le bon type de données. Si tu bosses avec des données temporelles internationales, prends TIMESTAMPTZ. Si juste la date suffit, reste sur DATE.

Teste tes requêtes. Vérifie que les résultats sont bien ce que tu veux, surtout si tu joues avec les intervalles, les formats ou les arrondis.

Stocke les données temporelles en UTC. C'est le meilleur moyen d'éviter la galère des fuseaux horaires.

Vérifie les formats. Assure-toi que le format dans TO_CHAR() et TO_DATE() colle à tes données.

Utilise les fonctions avec précaution. Mate bien la doc PostgreSQL sur les fonctions temporelles pour éviter les surprises cheloues.

Gérer les données temporelles, c'est pas toujours simple, mais avec la bonne méthode et un peu d'attention, ça roule tout seul. Les dates et l'heure, c'est crucial pour tes applis, et zapper ça, c'est aussi risqué que d'oublier de mettre ton réveil le lundi matin !