Types de données pour gérer le temps et les dates : DATE, TIME, TIMESTAMP, TIMESTAMPTZ

Dès qu'on commence à manipuler des données, y'a quasi toujours un truc lié au temps qui débarque. Pense aux horaires de vols, aux deadlines de commandes ou à la date d'inscription d'un utilisateur sur un site. Tout ça, c'est du temps. Et pour bosser proprement avec, il faut les bons outils. Dans PostgreSQL, t'as des types de données spéciaux qui gèrent super bien le stockage et le traitement des dates et des heures.

Bien sûr, tu pourrais enregistrer une date comme une simple chaîne de caractères genre "2023-10-12", mais c'est plus un piège qu'une vraie solution. Les chaînes savent pas comparer des dates, elles pigent pas ce que c'est « plus trois jours », et elles captent rien aux fuseaux horaires. Alors que les types temporels, eux, ils gèrent tout ça et même plus. Avec eux, c'est plus simple, plus fiable et plus rapide.

Type DATE

Le type DATE sert à stocker juste une date du calendrier, sans heure précise. C'est nickel si tu veux manipuler des dates comme des entités indépendantes, genre une date de naissance, le début d'une année, etc.

Exemples d'utilisation :

-- Exemple de création de table avec le type `DATE`
CREATE TABLE events (
    event_name TEXT,
    event_date DATE
);

-- Insertion de données
INSERT INTO events (event_name, event_date)
VALUES ('Conférence PostgreSQL', '2023-12-01'),
       ('Anniversaire', '2023-10-12');

-- Requête de sélection
SELECT * FROM events;

Résultat :

Type TIME

Le type TIME stocke UNIQUEMENT l'heure, c'est-à-dire les heures, minutes et secondes. Il est parfait pour tout ce qui est planning, genre les horaires de bus ou les créneaux d'ouverture des magasins.

Exemples :

-- Exemple de création de table avec `TIME`
CREATE TABLE schedules (
    schedule_name TEXT,
    start_time TIME,
    end_time TIME
);

-- Insertion de données
INSERT INTO schedules (schedule_name, start_time, end_time)
VALUES ('Heures de travail', '09:00:00', '18:00:00'),
       ('Pause déjeuner', '13:00:00', '14:00:00');

-- Requête de sélection
SELECT schedule_name, start_time, end_time FROM schedules;

Résultat :

Type TIMESTAMP

Le type TIMESTAMP combine une date du calendrier et une heure dans une seule valeur. Mais il NE gère PAS les fuseaux horaires. Ça peut vite devenir galère si tes données sont utilisées par des gens dans différents fuseaux.

Exemples :

-- Exemple de création de table avec `TIMESTAMP`
CREATE TABLE documents (
    document_id SERIAL PRIMARY KEY,
    created_at TIMESTAMP
);

-- Insertion de données
INSERT INTO documents (created_at)
VALUES ('2023-10-12 15:30:00'),
       ('2023-12-01 08:45:15');

-- Requête de sélection
SELECT document_id, created_at FROM documents;

Résultat :

Type TIMESTAMPTZ

Le type TIMESTAMPTZ (où TZ veut dire "fuseau horaire") ressemble à TIMESTAMP, mais il stocke en plus l'info du fuseau horaire. C'est juste indispensable pour les applis qui bossent avec des utilisateurs partout dans le monde.

Exemples :

-- Exemple de création de table avec `TIMESTAMPTZ`
CREATE TABLE meetings (
    meeting_id SERIAL PRIMARY KEY,
    meeting_time TIMESTAMPTZ
);

-- Insertion de données (PostgreSQL garde le fuseau horaire courant)
INSERT INTO meetings (meeting_time)
VALUES ('2023-10-12 15:30:00+03'),
       ('2023-12-01 08:45:15-05');

-- Requête de sélection
SELECT meeting_id, meeting_time FROM meetings;

Résultat :

Fais gaffe, PostgreSQL convertit automatiquement l'heure dans le fuseau horaire du serveur.

Avantages à utiliser des types de données spécialisés

Validité des données. Les types comme DATE et TIMESTAMP empêchent d'entrer des données bidons. Par exemple, tu peux pas enregistrer une date qui existe pas, genre "2023-02-30".

Facilité d'utilisation. Tu peux comparer des dates, les soustraire, choper la date du jour et même arrondir les valeurs (on verra ça plus tard).

Performance. Les types temporels prennent moins de place en mémoire et dans les index que les chaînes, donc les requêtes sont plus rapides.

Exemple : création d'une table avec tous les types

On va créer une table un peu plus costaude pour stocker le planning des événements. On va utiliser plusieurs types d'un coup : DATE, TIME, TIMESTAMP et TIMESTAMPTZ.

CREATE TABLE event_schedule (
    event_id SERIAL PRIMARY KEY,
    event_name TEXT NOT NULL,
    event_date DATE NOT NULL,
    start_time TIME NOT NULL,
    end_time TIME NOT NULL,
    full_start TIMESTAMP NOT NULL,
    full_start_with_zone TIMESTAMPTZ NOT NULL
);

-- Insertion des données
INSERT INTO event_schedule (
    event_name, event_date, start_time, end_time, full_start, full_start_with_zone
)
VALUES
    ('Meetup du matin', '2023-11-10', '10:00:00', '11:30:00', '2023-11-10 10:00:00', '2023-11-10 10:00:00+03'),
    ('Atelier du soir', '2023-11-11', '18:00:00', '20:00:00', '2023-11-11 18:00:00', '2023-11-11 18:00:00+03');

-- Vérification des données
SELECT * FROM event_schedule;

Résultat :

C'est un exemple de vraie base de données pour gérer des plannings. On voit comment différents formats de données temporelles se complètent selon le besoin.

J'espère que tu te rappelles maintenant comment utiliser les types DATE, TIME, TIMESTAMP et TIMESTAMPTZ dans PostgreSQL. Dans les prochaines leçons, on va creuser les fonctions temporelles et apprendre à extraire, formater et manipuler les données temporelles avec des requêtes SQL.