Timestamps Unix : les quatre pièges qui cassent vos dates

Un timestamp Unix n'est qu'un compte de secondes depuis le 1970-01-01 UTC. Simple — et pourtant les timestamps causent plus de bugs de dates que tout autre format. Quatre pièges expliquent l'essentiel.

1. Secondes vs millisecondes

Date.now() en JavaScript renvoie des millisecondes ; le temps Unix classique et la plupart des logs serveur utilisent des secondes. Un nombre à 10 chiffres est en secondes, à 13 en millisecondes. Les mélanger transforme 2026 en une date de l'an 53 000 — ou de 1970.

2. UTC vs heure locale

Le timestamp n'a pas de fuseau : c'est le même instant partout. Les bugs arrivent quand le code convertit avec le fuseau du serveur au lieu de celui de l'utilisateur, ou quand une chaîne comme 2026-09-01 08:00 est analysée sans dire à quel fuseau elle appartient.

3. Les sauts d'heure

Les zones avec heure d'été sautent d'une heure deux fois par an. Une réunion stockée comme 09:00 locale en été et en hiver correspond à deux instants UTC différents ; stocker en UTC et convertir à l'affichage élimine toute cette classe de bugs.

4. Analyse dépendante de la locale

03/04/2026 signifie le 4 mars dans un pays et le 3 avril dans un autre. Analyser une date depuis du texte exige un format explicite — jamais de devinettes.

Les règles qui marchent : stocker en UTC, convertir seulement à l'affichage, toujours nommer les formats. Pour inspecter un timestamp ou une date : le convertisseur de timestamps ou les horloges mondiales côte à côte — tout tourne dans votre navigateur.