Command Palette

Search for a command to run...

Convertisseur d'horodatage UNIX : époques, fuseaux horaires et bogue Year-57123

Convertisseur d'horodatage UNIX : époques, fuseaux horaires et bogue Year-57123

T
Toolz Team
|Jul 3, 2026|14 min read

Un utilisateur de l'une de mes applications Laravel SaaS a une fois envoyé un e-mail pour lui dire que la date de renouvellement de son abonnement avait l'air "un peu généreuse". La page de facturation lui a dit que son plan serait renouvelé le 25 avril de l'année. 57123.

Le bogue m'a mis de temps à être embarrassant à trouver car chaque pièce individuelle était correcte. Le frontend React envoyé Date.now() — qui revient millisecondes — Et le backend PHP a fait date('Y-m-d', $timestamp), qui attend instant. alimenter 1740470400000 dans une fonction attendant 1740470400 Et vous débarquez environ 55 000 ans dans le futur. Pas d'exception, pas d'avertissement, pas de test échoué. Juste un client demandant poliment si son abonnement avait vraiment duré jusqu'à la mort de la civilisation.

Les horodatages ressemblent au sujet le plus ennuyeux des logiciels. Ils sont en fait l'une des usines de bogues les plus fiables que nous ayons : secondes contre millisecondes, UTC vs locaux, transitions DST, le roulement de 2038. le Convertisseur d'horodatage sur toolz.dev existe parce que j'en avais assez de faire new Date(x * 1000) Dans une console de navigateur quarante fois par jour. Ce guide couvre ce que je vérifie maintenant, dans l'ordre où je le vérifie.

tl;dr : Un horodatage Unix compte des secondes depuis le 1970-01-01T00:00:00 UTC. 10 chiffres = secondes, 13 chiffres = millisecondes — Les mélanger met vos dates à 55 000 ans. Stockez UTC, convertissez uniquement pour l'affichage, utilisez les noms de zone IANA comme Asia/Dhaka au lieu d'abréviations. Collez n'importe quel horodatage dans le Convertisseur d'horodatage Pour obtenir les formulaires ISO 8601, RFC 2822, locaux et UTC, il exécute le client, ce qui permet de sortir des horodatages JWT Et les journaux de production ne quittent jamais votre navigateur.


Qu'est-ce qu'un horodatage Unix, exactement ?

Un horodatage Unix (heure de l'époque, temps POSIX) est le nombre de secondes écoulées depuis 1er janvier 1970, 00:00:00 UTC — L'époque "Unix". C'est un seul entier, il n'a pas de fuseau horaire (il est toujours UTC par définition), et effectivement chaque système d'exploitation, langage et base de données le comprend. Cette dernière propriété est la raison pour laquelle elle a survécu à cinq décennies : c'est le format unique auquel personne ne conteste.

Pourquoi 1970 ? Aucune raison profonde - c'était une date ronde pratique près de la construction d'UNIX chez Bell Labs, et le temps d'unix au début d'unix dans un entier de 32 bits. Le choix arbitraire fossilisé dans une norme universelle, qui est très Unix.

Quelques points de référence à reconnaître à vue :

horodatage Date UTC Pourquoi vous le verriez
0 1970-01-01 00:00:00 l'époque. Aussi ce que vous obtenez de null/0 Bugs - une date en 1970 à l'écran signifie presque toujours une valeur non initialisée, et non un voyage dans le temps
946684800 2000-01-01 00:00:00 Y2K
1234567890 2009-02-13 23:31:30 Les développeurs ont en fait organisé des parties pour celui-ci
1740470400 2025-02-25 08:00:00 Un horodatage moderne à 10 chiffres ordinaire
2147483647 2038-01-19 03:14:07 Le maximum signé 32 bits — voir Y2038 ci-dessous

Cette quatrième ligne est mon exemple préféré pour une raison subtile : beaucoup de listes de pages de didacticiel 1740470400 Comme "25 février 2025, 12:00:00" 08h00 UTC — Quelqu'un l'a converti dans son fuseau horaire local une fois et la valeur incorrecte a été copiée depuis. Vérifiez les horodatages avec un outil, pas avec un article de blog. Y compris celui-ci.

secondes ou millisecondes — comment dites-vous ?

Comptez les chiffres. Pour toute date de l'ère actuelle :

  • 10 chiffres (1740470400) — secondes. Convention UNIX, MOST APIS, PHP time(), Python time.time() (comme un flotteur), API de Stripe.
  • 13 chiffres (1740470400000) — millisecondes. Date.now(), Java System.currentTimeMillis(), dates de MongoDB.

C'est la distinction exacte qui a produit ma date de renouvellement de l'année 57123, donc je vais préciser les modes de défaillance :

  • MS interprété comme seconde → dates ~55 000 ans dans le avenir
  • secondes interprétées comme MS → dates dans Janvier 1970 (Tout s'effondre à environ 3 semaines après l'époque)

Si vous voyez une signature - dates anciennes ou dates lointaines absurdes - vous connaissez le bogue avant de lire une ligne de code. le Convertisseur d'horodatage Détecte le nombre de chiffres et étiquette les deux interprétations, ce qui règle l'argument "est-ce S ou MS ?" en deux secondes.

Quels formats de date avez-vous réellement besoin de connaître ?

Trois couvrent presque tout ce qu'un développeur en activité touche.

ISO 8601 — La norme internationale, et ce que vous devez émettre dans les API et les journaux :

2026-07-13T09:30:45Z          UTC ("Z" = Zulu)
2026-07-13T15:30:45+06:00     with timezone offset
2026-07-13T09:30:45.123Z      with milliseconds

La fonctionnalité de tueur que personne ne mentionne : les chaînes ISO 8601 Trier lexicographiquement par ordre chronologique. sort Sur un fichier journal, cela fonctionne. 02/25/2026-Les formats de style ne peuvent pas faire cela - et pire encore, nous MM/DD et européen DD/MM sont indissociables pendant douze jours de chaque mois.

RFC 3339 (spécification) — Le profil Internet-protocole de l'ISO 8601. Légèrement plus strict ; si votre API émet 2026-07-13T09:30:45Z Vous satisfais les deux. C'est le format sur lequel standardiser.

RFC 2822 (Sun, 13 Jul 2026 09:30:45 +0000) — En-têtes de courrier électronique et HTTP, flux RSS. Vous le lisez plus souvent que vous ne l'écrivez.

Les formats de base de données sont proches de la cousine : mySQL DATETIME est 2026-07-13 09:30:45 (ISO avec un espace), PostgreSQL timestamptz enthousiasme 2026-07-13 09:30:45+00.

Comment les langues que j'utilise gèrent-elles les horodatages ?

Les trois de ma propre pile - et la bizarrerie de chacun qui m'a personnellement coûté du temps.

Javascript (le MS) :

Math.floor(Date.now() / 1000)        // current Unix seconds — Date.now() is ms!
new Date(1740470400 * 1000)          // seconds → Date: multiply by 1000
date.toISOString()                   // "2025-02-25T08:00:00.000Z"
Date.parse('2026-07-13T09:30:45Z') / 1000   // ISO string → Unix seconds

Quirk : tout est en millisecondes, et new Date(1740470400) Vous donne en silence le 21 janvier 1970 au lieu de février 2025. Pas d'erreur. Cette asymétrie est le bogue d'horodatage le plus courant dans le développement Web.

PHP (la seconde) :

time();                                   // current Unix seconds
date('Y-m-d H:i:s', 1740470400);          // "2025-02-25 08:00:00" (server TZ!)
strtotime('2026-07-13 09:30:45');         // string → timestamp
(new DateTime('@1740470400'))
    ->setTimezone(new DateTimeZone('Asia/Dhaka'))
    ->format(DateTime::ATOM);             // "2025-02-25T14:00:00+06:00"

bizarrerie : date() formats dans le Serveur Fuseau horaire par défaut, donc le même code imprime différentes dates sur votre machine et en production. Aussi, new DateTime('@1740470400') Ignore tout fuseau horaire que vous transmettez au constructeur — le @ Le formulaire est toujours UTC ; vous devez appeler setTimezone() Après. WordPress ajoute son propre calque : current_time('timestamp') Retourne un faux "local" décalé d'horodatage par rapport à l'heure Unix réelle, ce qui est exactement aussi dangereux que cela puisse paraître.

python:

import time, datetime
int(time.time())                                      # current Unix seconds
datetime.datetime.fromtimestamp(1740470400,
    tz=datetime.timezone.utc)                         # → aware datetime
dt.isoformat()                                        # "2025-02-25T08:00:00+00:00"

bizarrerie : fromtimestamp() à l'extérieur tz= Renvoie une date naïve à l'heure locale. Les dates naïves sont le bug de l'heure Python : ils se comparent et se soustraient joyeusement les uns contre les autres jusqu'au jour où l'un d'entre eux a franchi une limite DST. Toujours passer tz=; utiliser zoneinfo (stdlib depuis 3,9) pour les zones nommées.

Comment gérer les fuseaux horaires sans perdre la tête ?

Quatre règles, toutes ont appris de manière agaçante :

  1. Stockez UTC. Toujours. Horodatage Unix ou timestamptz dans la base de données. Le fuseau horaire devient uniquement un problème d'affichage.
  2. Convertir au niveau de la couche de présentation. L'utilisateur de Dhaka voit +06:00, l'utilisateur de Berlin voit +02:00, la base de données ne voit ni l'un ni l'autre.
  3. Utilisez des noms IANA, pas des abréviations. Asia/Dhaka, America/New_York, Europe/Berlin. Les abréviations sont ambiguës — CST signifie une heure centrale aux États-Unis, en Chine, en heure normale ou à l'heure normale de Cuba, en fonction de la lecture de qui - et les abréviations n'encodent pas les règles DST. Les noms de l'IANA le font.
  4. Ne jamais rouler la logique DST à la main. Les dates des DST diffèrent selon le pays, les modifications législatives, et certains endroits (Arizona, Bangladesh, Japon) ne respectent pas du tout l'heure d'été. La base de données IANA TZ existe car cela est vraiment difficile, utilisez la bibliothèque qui l'enveloppe.

Le corollaire de la règle 1 : lorsque deux systèmes sont en désaccord sur une durée d'événement, convertissez les deux valeurs en horodatages UTC Unix et comparez les nombres entiers. Arguments sur "mais il est indiqué 15h00 ici" dissolvent instantanément.

Quel est le problème Y2038 et devriez-vous vous en soucier ?

Un entier signé 32 bits maximise le 2,147,483,647. En tant qu'horodatage d'UNIX, c'est 19 janvier 2038, 03:14:07 UTC. Une seconde plus tard, la valeur s'achève négativement — jusqu'au 13 décembre 1901.

Cela semble loin; ce n'est pas le cas, pour deux raisons. Premièrement, il y a environ 11,5 ans, au moment où j'écris ceci - bien dans la durée de vie des systèmes embarqués, des contrôleurs industriels et de ce service hérité que personne ne veut toucher. Deuxièmement, avenir Les dates sont entrées en place tôt dans le mur : un système qui calcule un calendrier hypothécaire de 15 ans ou un certificat d'expiration de 20 ans contre les traversées en 2038 aujourd'hui. MySQL TIMESTAMP Le type de colonne est le piège classique - il est limité sur 32 bits et ne peut pas stocker les dates après le 2038-01-19, tandis que DATETIME Dans la même base de données, c'est bien.

Vous êtes en sécurité sur 64 bits time_t (Tout moderne OS), JavaScript (Float64 MS), Python (précision arbitraire) et PostgreSQL. Vous êtes à risque sur des systèmes embarqués 32 bits, anciens TIMESTAMP colonnes et code C qui a codé en dur int32_t Pour le temps. Le test est simple : pousser 2147483648 (un après la limite) à travers votre pipeline et voyez ce qui sort. le Convertisseur d'horodatage vous générera avec plaisir les valeurs de test après 2038.

Où les horodatages apparaissent-ils dans le débogage réel ?

expiration JWT. Les jetons portent iat et exp Réclamations en secondes Unix :

{ "sub": "user_8241", "iat": 1783915890, "exp": 1783919490 }

"Pourquoi cet utilisateur est-il déconnecté ?" est répondu en convertissant exp. Décodez le jeton dans le Décodeur JWT et convertissez la réclamation - les deux exécutent le côté client, ce qui compte, car un jeton collé est un identifiant en direct (le Guide de confidentialité des données explique pourquoi je refuse de mettre des jetons dans les outils côté serveur).

Corrélation des logs. Un incident, trois services, trois formats : Journaux NGINX [13/Jul/2026:09:30:45 +0000], l'application enregistre la norme ISO 8601, un travailleur de file d'attente enregistre des secondes d'époque. Tout convertir en un seul format est l'étape zéro de la création d'un calendrier.

Intégration de l'API. Stripe envoie "created": 1740470400 (secondes). Une API construite par JavaScript envoie 1740470400000 (ms). Les API Google envoient des chaînes RFC 3339. Si vous consommez les trois, la conversion n'est pas occasionnelle, c'est constant. Formatez les charges utiles dans le Formateur JSON et convertir les champs intéressants.

requêtes de plage de dates. WHERE created_at >= 1752364800 AND created_at < 1752451200 — C'est le bon jour ? Convertir les deux limites et vérifier, en UTC, avant d'exécuter la suppression. Connexe : le Calculateur de différence de date Pour "Combien de jours entre ces deux ?", le Convertisseur de fuseau horaire pour les mathématiques et les analyseur Pour "quand ce calendrier se déclenche-t-il réellement ?".

Questions fréquentes

Qu'est-ce qu'un horodatage Unix ?

Le nombre de secondes s'est écoulé depuis le 1er janvier 1970, 00:00:00 UTC (l'époque UNIX), stockée en un seul nombre entier. Il est par définition indépendant du fuseau horaire - le même instant est le même partout sur Terre - c'est pourquoi il s'agit du format d'échange standard entre les systèmes d'exploitation, les langues et les bases de données.

Pourquoi certains horodatages ont-ils 10 chiffres et d'autres 13 ?

10 chiffres est une seconde (convention Unix standard, PHP, la plupart des API) ; 13 chiffres sont des millisecondes (JavaScript&#39;s Date.now(), Java). Divisez par 1 000 sur les MS en secondes. La confusion des deux quarts de travail date d'environ 55 000 ans dans le futur ou de janvier 1970.

Les horodatages d'UNIX peuvent-ils représenter des dates avant 1970 ?

Oui — Les valeurs négatives comptent à l'arrière à partir de l'époque. -86400 est le 31 décembre 1969. Un horodatage signé 32 bits remonte au 13 décembre 1901. Certains systèmes et API rejettent cependant les horodatages négatifs, alors testez avant de vous y fier.

Quel est le problème Y2038 ?

Les horodatages signés 32 bits débordent à 2 147 483 647 – 19 janvier 2038, 03:14:07 UTC — Enveloppement jusqu'en décembre 1901. Les systèmes modernes 64 bits ne sont pas affectés, mais les périphériques embarqués 32 bits, le code C hérité et MySQL TIMESTAMP Les colonnes sont exposées. Les dates de calcul des systèmes lointains (hypothèques, certificats) ont touché le bogue des années avant l'arrivée de 2038.

Pourquoi ma date est-elle visible janvier 1970 ?

Un horodatage nul ou proche n'a pas atteint votre code de mise en forme - généralement une valeur non initialisée, une analyse parselée qui a échoué renvoyant 0 ou les secondes s'est écoulée là où des millisecondes étaient attendues. Une date à l'écran de 1970 n'est presque jamais un point de données, c'est un null portant un costume.

Dois-je stocker des horodatages ou des chaînes de dates dans ma base de données ?

Stockez UTC dans les deux sens - le type compte moins que la discipline du fuseau horaire. Les entiers Unix sont compacts, triés de manière triviale et analysent entièrement l'analyse ; timestamptz/DATETIME Les colonnes sont lisibles par l'homme dans les résultats de requête et prennent en charge l'arithmétique de date dans SQL. Ce que vous ne devez pas faire, c'est de stocker les heures locales sans décalage, c'est la perte de données que vous ne découvrez qu'à la prochaine transition DST.

L'époque est-elle affectée par les secondes intercalaires ?

Pratiquement, le temps Unix prétend que les secondes ne leapse n'existent pas - chaque jour est exactement 86 400 secondes, et les systèmes généralement étalent ou marchent sur l'horloge lorsqu'un instant de pas de fuite se produit. Pour le code d'application, il s'agit d'un non-problème, mais uniquement dans les contextes de synchronisation scientifique, où le temps de TAI ou de GPS est utilisé à la place.

Est-il sûr de coller des horodatages de la production en ligne dans un convertisseur en ligne ?

Un horodatage brut à lui seul révèle peu, mais les horodatages voyagent généralement avec le contexte - ID utilisateur, revendications de jetons, lignes de journal. le Convertisseur d'horodatage Sur Toolz.dev se convertit entièrement dans votre navigateur sans aucune donnée transmise, donc coller des valeurs directement à partir de journaux de production ou JWT n'expose rien.

Comment convertir un horodatage Unix en une date lisible ?

Collez le nombre dans un convertisseur et lisez les résultats UTC et locaux, ou faites-le dans le code : new Date(ts * 1000).toISOString() En Javascript, datetime.fromtimestamp(ts, tz=timezone.utc) En Python, date -u -d @ts sous Linux. La seule chose à faire en premier est de savoir si votre valeur est en secondes ou en millisecondes - tout le reste découle de cela.

Comment obtenir l'horodatage UNIX actuel ?

date +%s Dans une coquille, Math.floor(Date.now() / 1000) En Javascript, int(time.time()) En Python, SELECT EXTRACT(EPOCH FROM NOW()) dans PostgreSQL. Notez que JavaScript est l'intrus : Date.now() Renvoie des millisecondes, la division n'est donc pas facultative.

Frequently Asked Questions

The number of seconds elapsed since January 1, 1970, 00:00:00 UTC (the Unix epoch), stored as a single integer. It's timezone-independent by definition — the same instant is the same number everywhere on Earth — which is why it's the standard interchange format across operating systems, languages, and databases.

Comments

0 comments

0/2000 characters

No comments yet. Be the first to share your thoughts!