Aller au contenu principal
ToolsByUs

Convertir un timestamp

Convertisseur de timestamps Unix transforme un timestamp en toutes les écritures utiles d’un même instant, et inversement. L’unité est détectée d’après l’ordre de grandeur et annoncée : le même entier correspond à un moment de 1970 ou de 2026 selon qu’il compte des secondes ou des millisecondes, et un convertisseur qui devine en silence produit une date plausible et fausse d’un facteur mille.

100 % local

Saisissez un horodatage ou une date ISO, ou choisissez « Maintenant, ici » ou un exemple.

Comment fonctionne Convertir un timestamp ?

L’arithmétique est triviale. Savoir ce que représente réellement le nombre que vous avez sous les yeux ne l’est pas, et c’est là que les erreurs arrivent.

Un timestamp Unix ne porte aucune unité

1757577600 en secondes depuis 1970 tombe le 11 septembre 2025. Lu comme des millisecondes, il tombe le 21 janvier 1970. Lu comme des microsecondes, vingt-neuf minutes après minuit le 1er janvier 1970. Rien dans la valeur n’indique lequel, donc l’unité est déduite de l’ordre de grandeur — dix chiffres ou moins, des secondes ; onze à treize, des millisecondes, et ainsi de suite — et la déduction est affichée à côté du résultat au lieu d’être appliquée en silence. La distinction compte : une déduction visible est un fait que vous pouvez corriger.

L’an 2038 n’est pas hypothétique

Un time_t signé sur 32 bits s’arrête à 03:14:07 UTC le 19 janvier 2038, où il déborde sur 1901. Les systèmes d’exploitation modernes sont passés à 64 bits il y a des années, mais pas les firmwares embarqués, les anciens formats de fichiers ni certaines colonnes de base de données, et du code qui stocke un timestamp dans une colonne INT a le même plafond. Il figure dans les exemples ci-dessous parce qu’il est utile de tester contre cette limite.

Un décalage horaire appartient à l’instant, pas au fuseau

Londres est à +00:00 en janvier et +01:00 en juillet, donc « Europe/London » n’identifie pas un décalage — il identifie un ensemble de règles pour dériver un décalage d’une date. La sortie ISO ici lit le décalage de votre instant précis dans la base de données des fuseaux horaires de la plateforme au lieu de le calculer — c’est ce qui la rend correcte de part et d’autre d’un changement d’heure. Tout ce qui code un décalage en dur se trompe deux fois par an.

Le temps Unix n’a pas de secondes intercalaires

Un timestamp Unix est défini comme le nombre de secondes hors secondes intercalaires depuis l’époque, ce qui signifie qu’il ne peut pas en représenter une. Quand une seconde intercalaire est insérée, les implémentations répètent une valeur ou étalent la seconde supplémentaire sur une journée. La différence entre deux timestamps Unix n’est donc pas exactement le temps physique écoulé — 27 secondes d’écart depuis 1972, ce qui n’a d’importance pour presque rien et en a énormément pour les rares cas où cela en a.

Les numéros de semaine ISO ne sont pas ceux qu’on attend

Selon ISO 8601, une semaine commence le lundi et la semaine 1 est celle qui contient le premier jeudi, donc le 1er janvier tombe parfois en semaine 52 ou 53 de l’année précédente. Voilà pourquoi un tableau de bord peut afficher une semaine 53 qu’un autre affiche comme semaine 1, et les deux ont raison selon des règles différentes.

Entrée

1757577600

Résolu

unit      seconds (10 digits or fewer)
ISO       2025-09-11T08:00:00.000Z
RFC 2822  Thu, 11 Sep 2025 08:00:00 GMT
relative  last year

Quelles options et quels cas limites Convertir un timestamp prend en charge ?

Référence technique et options
ParamètreTypeValeur par défautComportement et cas limites
10 chiffres ou moinssecondesdétectéL’unité classique de l’epoch Unix, et ce que presque toutes les API et bases de données entendent par timestamp.
11 à 13 chiffresmillisecondesdétectéCe que renvoie Date.now de JavaScript, et ce qu’émettent la plupart des API JSON écrites en JavaScript.
14 à 16 chiffresmicrosecondesdétectéLes horodatages internes de Postgres et time.time_ns de Python divisé par mille.
17 chiffres ou plusnanosecondesdétectétime.UnixNano de Go et le format d’exposition de Prometheus.
ISO 8601chaîne de dateaccepté2026-09-11T08:00:00Z et ses variantes. Une chaîne ISO sans fuseau est lue comme heure locale par la plateforme ; c’est une vraie ambiguïté du format, et non un choix fait ici.
Relatifexpressionaccepté`3 days ago`, `2 hours`, `now`. Mois et année sont des approximations, car aucun des deux n’a de durée fixe.
Fuseau horairenom IANAvotre fuseau localLe décalage est lu dans la base de données de la plateforme pour cet instant précis ; il est donc correct des deux côtés d’un changement d’heure d’été.
Semaine ISO1 à 53calculéLes semaines commencent le lundi ; la semaine 1 contient le premier jeudi. Le 1er janvier peut donc se trouver en semaine 52 ou 53 de l’année précédente.

Questions fréquentes

Pourquoi mon timestamp tombe-t-il en 1970 ?

Vous avez très certainement collé des secondes dans un champ qui attend des millisecondes, ou l’inverse. Cet outil détecte l’unité d’après l’ordre de grandeur et vous dit laquelle il a choisie : vérifiez d’abord cette ligne. Un nombre à dix chiffres est en secondes ; à treize chiffres, en millisecondes. Multiplier ou diviser par mille — c’est toute la correction.

Secondes ou millisecondes — que doit utiliser mon API ?

Des secondes, sauf si vous avez réellement besoin d’une précision infra-seconde, et dites-le dans votre documentation dans tous les cas. Les secondes, c’est ce que désigne un timestamp pour Unix, la plupart des bases de données et la plupart des langages ; les millisecondes, ce que désigne JavaScript. Les bugs naissent de la frontière entre les deux, donc la discipline utile consiste à nommer l’unité dans le nom du champ lui-même : created_at_ms plutôt que created_at.

Que se passera-t-il vraiment en 2038 ?

Un time_t signé sur 32 bits déborde à 03:14:07 UTC le 19 janvier 2038 et repart en décembre 1901. Les systèmes 64 bits s’en tirent, et depuis des années ; ce qui ne va pas, ce sont les firmwares embarqués qui tourneront encore, les formats de fichiers avec un champ 32 bits, et les colonnes de base de données typées INT plutôt que BIGINT. Ces dernières sont celles qui ont le plus de chances de se trouver dans votre codebase en ce moment.

Pourquoi ma chaîne ISO a-t-elle une heure de décalage ?

Généralement, l’heure d’été. Un décalage est une propriété d’un instant précis, pas d’un fuseau : Londres est à +00:00 en janvier et +01:00 en juillet. Cet outil lit le décalage dans la base de données des fuseaux horaires de la plateforme pour votre instant exact, donc il change au passage de la limite — ce qui est correct, et c’est pourquoi un décalage codé en dur est faux la moitié de l’année.

Le temps Unix tient-il compte des secondes intercalaires ?

Non, par définition — il compte des secondes hors secondes intercalaires, donc il n’a aucun moyen d’en représenter une. Quand une seconde intercalaire est insérée, les systèmes répètent une valeur de timestamp ou étalent la seconde supplémentaire sur la journée. Conséquence pratique : soustraire deux timestamps Unix donne un temps civil écoulé, pas un temps physique ; l’écart est de 27 secondes depuis 1972.

Mon timestamp est-il envoyé ?

Non. Chaque conversion ici est de l’arithmétique plus la base de données des fuseaux horaires Intl du navigateur, exécutées dans l’onglet déjà ouvert. Rien dans la conversion d’une date n’exige un serveur, et les timestamps que l’on convertit sortent généralement de logs de production.

Équipe ToolsByUs · Comment nous vérifions nos outils