Timestamp Unix en base de données

Mis à jour : mai 2026

Les bases de données peuvent stocker le temps sous forme d'entier Unix, de type timestamp natif ou de chaîne ISO 8601. Le meilleur choix dépend de vos requêtes, de votre ORM et du besoin d'affichage.

Convertir une valeur SQL

Gratuit · sans upload · calcul local

PostgreSQL

-- Timestamp Unix vers timestamptz
SELECT to_timestamp(1735689600);

-- Date vers timestamp Unix
SELECT EXTRACT(EPOCH FROM TIMESTAMPTZ '2025-01-01 00:00:00+00')::bigint;

-- Affichage Europe/Paris
SELECT to_timestamp(1735689600) AT TIME ZONE 'Europe/Paris';

PostgreSQL gère très bien les types timestamp et timestamptz. Préférez timestamptz pour les instants réels.

MySQL

SELECT FROM_UNIXTIME(1735689600);
SELECT UNIX_TIMESTAMP('2025-01-01 00:00:00');

Attention : MySQL dépend souvent du fuseau horaire de session. Fixez-le explicitement si vos conversions doivent être reproductibles.

SQLite

SELECT datetime(1735689600, 'unixepoch');
SELECT strftime('%s', '2025-01-01 00:00:00');

Entier ou type natif ?

Entier Unix : compact, simple à indexer, pratique pour les APIs.
Type timestamp : plus expressif, fonctions SQL riches, lisible dans les outils d'administration.
Texte ISO : lisible et portable, mais moins optimal pour les calculs massifs.

Bonne pratique

Utilisez un type 64 bits si vous stockez des timestamps Unix. Documentez l'unité dans le schéma ou le commentaire de colonne : secondes, millisecondes, microsecondes. Une colonne created_at ambiguë finit toujours par coûter du temps.

Questions fréquentes

Faut-il stocker en UTC ?

Oui pour les instants réels. Le fuseau utilisateur doit être appliqué à l'affichage.

Un timestamp Unix est-il indexable ?

Oui. C'est même l'un de ses avantages : les comparaisons et tris sont directs.

BIGINT ou INTEGER ?

Pour les secondes, INTEGER peut suffire selon la base, mais BIGINT évite les limites 32 bits et les millisecondes imposent souvent BIGINT.