Convertir des horodatages UNIX et gérer les fuseaux horaires en sécurité

Un horodatage UNIX représente un instant comme une durée depuis l’époque UNIX. Il ne contient pas un fuseau nommé, une règle d’heure d’été ni une étiquette de calendrier. Ces règles interviennent lorsque l’instant est affiché pour une personne ou un lieu.

Réponse rapide : déterminez d’abord l’unité. Les valeurs actuelles à dix chiffres utilisent souvent les secondes. Les valeurs actuelles à treize chiffres utilisent souvent les millisecondes. Convertissez la valeur en instant. Formatez ensuite cet instant en UTC ou dans un fuseau IANA nommé. Ne traitez jamais un décalage UTC fixe comme un fuseau complet.

Cette page explique les unités d’époque, les valeurs négatives, UTC, les décalages, les transitions saisonnières, le texte ISO 8601, les limites JavaScript et les conversions de temps de fichier Windows. Elle accompagne le convertisseur d’horodatage UNIX et la collection de dates, heures et horodatages.

Qu’est-ce qu’un horodatage UNIX ?

L’époque UNIX commence à 1970-01-01 00:00:00 UTC. Un horodatage UNIX compte généralement les secondes depuis cet instant de référence, sans secondes intercalaires. Une valeur positive identifie un instant postérieur. Une valeur négative identifie un instant antérieur lorsque le système l’accepte.

Le modèle temporel POSIX définit les secondes depuis l’époque avec des règles de conversion calendaire. RFC 9636 définit le temps UNIX comme des secondes entières depuis l’époque POSIX, sans secondes intercalaires. Les implémentations et langages peuvent accepter des intervalles ou précisions plus limités.

Un horodatage n’est pas une date affichée. Un même instant peut apparaître comme des dates locales différentes à Tokyo, Kolkata, Londres et New York. L’horodatage ne change pas. La présentation change selon les règles du fuseau.

Type de valeur	Exemple	Signification	Risque principal
Secondes UNIX	1725148800	Secondes depuis l’époque	Les confondre avec des millisecondes
Millisecondes UNIX	1725148800000	Millisecondes depuis l’époque	Les confondre avec des secondes
Date et heure ISO avec Z	2024-09-01T00:00:00Z	Instant UTC	Perdre Z pendant l’analyse
Date et heure ISO avec décalage	2024-09-01T05:30:00+05:30	Instant et décalage numérique	Traiter le décalage comme un fuseau nommé
Date et heure locale	2024-09-01 05:30	Champs de calendrier sans instant unique	Zone et choix de chevauchement absents

Un horodatage UNIX dépend-il des fuseaux horaires ?

Non. Un horodatage UNIX valide identifie un instant sans dépendre du fuseau d’affichage. Le fuseau intervient lorsque cet instant devient des champs de calendrier local.

Réponse directe : n’ajoutez ni ne soustrayez un décalage local pour « convertir » le fuseau d’un horodatage UNIX. Conservez l’instant et demandez à une bibliothèque de fuseaux de le formater dans la zone cible.

L’arithmétique manuelle des décalages échoue lorsqu’un lieu change de décalage. L’heure d’été crée des changements saisonniers. Les gouvernements peuvent réviser les règles civiles. Les décalages historiques peuvent différer des décalages actuels. Certaines régions utilisent des décalages qui ne sont pas des heures entières.

La base IANA des fuseaux horaires conserve les règles civiles actuelles et historiques pour des lieux représentatifs. Les systèmes la mettent à jour lorsque les règles changent. America/New_York contient un historique de règles. -05:00 ne contient qu’un décalage numérique.

Comment distinguer secondes et millisecondes ?

Aucune règle fondée sur le nombre de chiffres ne fonctionne pour toutes les dates. La grandeur donne une indication pratique pour les dates actuelles, mais ne constitue pas un type formel. Une interface robuste doit demander l’unité ou montrer son inférence.

Près de l’époque actuelle, les secondes UNIX ont souvent dix chiffres. Les millisecondes en ont souvent treize. Les microsecondes et nanosecondes ont des valeurs plus grandes. Les dates futures, valeurs négatives, zéros initiaux, décimales et chaînes rendent le test de longueur incertain.

Utilisez ce processus :

1. Lisez la documentation du système source.
2. Conservez la valeur comme texte jusqu’à connaître son unité et son intervalle.
3. Sélectionnez explicitement secondes, millisecondes, microsecondes ou nanosecondes.
4. Utilisez une bibliothèque qui gère les grands entiers lorsque la précision compte.
5. Comparez l’année produite à l’intervalle métier attendu.
6. Affichez UTC et le fuseau nommé prévu.

Si 1725148800 produit une date proche de janvier 1970, le convertisseur a probablement traité des secondes comme des millisecondes. Si 1725148800000 produit une date située très loin dans le futur, il a probablement traité des millisecondes comme des secondes. Une année plausible aide à vérifier, mais la documentation du producteur reste l’autorité.

Pourquoi JavaScript peut-il perdre la précision temporelle ?

JavaScript Number utilise le flottant binaire IEEE 754. Il représente exactement les entiers seulement dans un intervalle sûr. Les millisecondes actuelles y tiennent largement. Les nanosecondes n’y tiennent pas toujours.

ECMAScript Date stocke une valeur temporelle en millisecondes. La spécification ECMAScript des dates définit la valeur et l’intervalle. Les implémentations refusent les valeurs hors intervalle. L’analyse dépend aussi de la grammaire et de la présence d’une zone.

Utilisez BigInt ou une bibliothèque adaptée aux microsecondes et nanosecondes. Ne convertissez pas une grande chaîne entière en Number avant de vérifier son intervalle. L’arrondi peut modifier silencieusement les chiffres inférieurs et l’instant.

Lorsqu’une API renvoie des horodatages, indiquez l’unité dans le nom du champ ou le schéma. createdAtEpochSeconds est plus sûr que timestamp. Le producteur et le consommateur ont besoin d’un contrat explicite.

Quelle différence entre UTC, décalages et zones nommées ?

UTC est l’échelle temporelle commune pour les instants mondiaux. Un décalage UTC indique la différence entre l’heure locale et UTC à un instant. Une zone nommée apporte les règles qui déterminent ce décalage selon la date.

Concept	Exemple	Change avec la date	Identifie un instant seul
Marqueur UTC	Z	Non	Oui, avec date et heure
Décalage numérique	+05:30	La valeur ne change pas	Oui, avec date et heure
Zone IANA	Asia/Kolkata	Peut changer	Non, sans date et heure locale
Heure murale locale	2026-11-01 01:30	Ne s’applique pas	Non

Une zone nommée peut associer une heure locale à deux instants pendant un recul d’horloge. Elle peut aussi l’associer à aucun instant pendant une avance. Les bibliothèques appellent ces cas des chevauchements et des trous. L’application doit définir sa politique de désambiguïsation.

Pour planifier des événements, conservez la sémantique voulue. Une réunion unique peut conserver un instant et une zone d’affichage. Un rendez-vous récurrent à 09:00 peut exiger une heure locale, une zone nommée, une règle et un comportement lorsque la base change. Enregistrer seulement le premier instant peut déplacer les rendez-vous futurs.

Que se passe-t-il pendant les transitions d’heure d’été ?

Pendant une transition de printemps, les horloges avancent. Un intervalle local peut ne pas exister. Pendant une transition d’automne, elles reculent. Un intervalle local peut arriver deux fois avec des décalages différents.

Une heure locale comme 01:30 peut apparaître deux fois. Une chaîne qui contient seulement la date et l’heure ne dit pas quel instant l’utilisateur voulait. Ajoutez un décalage numérique ou une règle explicite précédente ou suivante avec une bibliothèque nommée.

La proposition ECMAScript Temporal modélise ces différences. Sa documentation ZonedDateTime explique l’heure exacte, la zone et le calendrier. Elle expose aussi la désambiguïsation des trous et chevauchements. Vérifiez le support avant de dépendre d’une proposition.

Ne conservez pas éternellement les décalages en cache. Mettez à jour l’environnement ou la base qui fournit les données IANA. Gardez serveur, client, conteneur et images de base à jour. Une base obsolète peut faire calculer des heures locales différentes pour un même événement futur.

Comment formater un instant ?

Utilisez un format lisible par machine avec un marqueur UTC ou un décalage explicite. RFC 3339 définit un profil date-heure courant sur Internet. La spécification RFC 3339 définit la date complète, l’heure, les décalages et les fractions facultatives.

Exemples :

• 2026-09-01T12:00:00Z identifie midi UTC.
• 2026-09-01T17:30:00+05:30 identifie le même instant avec un décalage.
• 2026-09-01T12:00:00.123Z ajoute une précision de millisecondes.
• 2026-09-01 12:00:00 ne déclare ni zone ni décalage.

Utilisez T et Z en majuscules lorsque l’interopérabilité compte. Conservez la précision fractionnaire nécessaire. N’ajoutez pas de chiffres sans signification. Une source précise à la seconde ne gagne pas une précision nanoseconde par l’ajout de zéros.

Pour les nouveaux protocoles qui doivent porter une zone nommée, examinez le format étendu de RFC 9557. Ajoutez les annotations entre crochets aux horodatages RFC 3339 et confirmez le support des consommateurs.

Quel effet les secondes intercalaires ont-elles sur le temps UNIX ?

UTC peut contenir des secondes intercalaires. Les représentations UNIX et POSIX courantes n’associent pas chaque étiquette intercalaire à un horodatage ordinaire par une correspondance continue simple. Les systèmes peuvent ignorer, répéter, lisser ou traiter l’événement avec des horloges spécialisées.

Le projet IANA tz documente les décisions et les limites dans son fichier théorique. Les bibliothèques visent généralement les instants civils et non les mesures scientifiques de haute précision.

Si l’application traite des données financières, satellites, journaux distribués ou mesures scientifiques, définissez l’échelle temporelle. UTC, TAI, GPS, horloges monotones et horloges système répondent à des besoins différents. Un convertisseur du navigateur ne doit pas faire autorité pour la haute précision.

Utilisez une horloge monotone pour mesurer des durées dans un processus. L’horloge civile peut changer par synchronisation, administration ou virtualisation. Enregistrez les instants d’événements pour les audits et mesurez les durées avec l’interface monotone de la plateforme.

Comment convertir un horodatage UNIX en sécurité ?

Suivez ce flux :

1. Identifiez le système source et l’unité.
2. Conservez la valeur originale pour l’audit et le diagnostic.
3. Validez la syntaxe, le signe, l’intervalle et la précision permise.
4. Convertissez en instant sans appliquer manuellement un décalage local.
5. Formatez l’instant en UTC comme référence stable.
6. Formatez le même instant dans la zone IANA demandée.
7. Affichez le décalage numérique utilisé à cette date.
8. Comparez l’année et le contexte local avec l’attendu.

Le convertisseur d’horodatage UNIX fournit un flux dédié. Utilisez d’abord des exemples. L’outil du navigateur aide à inspecter une valeur, mais le contrat de l’API source décide de l’unité.

Pour des conversions massives ou de production, utilisez une bibliothèque maintenue. Fixez et mettez à jour ses données de fuseau. Ajoutez des tests pour les trous, chevauchements, changements d’année, valeurs négatives, fractions et limites maximales.

Quelle différence avec les heures de fichier Windows ?

L’heure de fichier Windows et le temps UNIX utilisent des époques et unités différentes. Une valeur FILETIME compte généralement des intervalles de 100 nanosecondes depuis 1601-01-01 UTC. Le temps UNIX compte généralement les secondes depuis 1970-01-01 UTC.

La conversion exige un décalage d’époque et un facteur d’unité. L’arithmétique d’entiers larges compte, car FILETIME peut dépasser la plage sûre de JavaScript. Une conversion en Number peut supprimer les chiffres finaux.

Utilisez l’outil UNIX vers Windows Filetime pour une conversion contrôlée. Utilisez l’outil Windows Filetime vers UNIX dans l’autre sens. Conservez l’entier original comme texte et vérifiez le résultat avec une autre implémentation pour les usages forensiques.

La documentation Windows sur les heures de fichier décrit les intervalles de 100 nanosecondes. Les systèmes de fichiers peuvent avoir une résolution, une mise à jour ou une conversion locale différente. L’unité nominale ne prouve pas une mesure à cette précision.

Conseils pour les bases de données et les API

Utilisez un type qui correspond au modèle. Une colonne de base de données avec zone peut normaliser un instant, mais chaque fournisseur a sa sémantique. Une colonne sans zone peut représenter des champs locaux. Lisez la documentation avant une migration.

Pour les événements API, envoyez une chaîne RFC 3339 avec Z ou un entier documenté avec une unité explicite. Évitez les valeurs sans contrat. Ajoutez séparément une zone nommée lorsque le métier en a besoin.

Pour les rendez-vous futurs, conservez plus qu’un instant lorsque l’heure locale doit rester stable. Un enregistrement peut inclure :

• la date et l’heure locales ;
• l’identifiant de zone IANA ;
• la règle de répétition ;
• le choix de désambiguïsation ;
• l’entrée originale de l’utilisateur ;
• le prochain instant calculé ;
• la politique de mise à jour des règles.

Pour les événements passés, gardez l’instant et le contexte utile. Le décalage aide à l’affichage et au diagnostic. La zone nommée peut encore compter pour l’interprétation humaine.

Erreurs courantes avec les horodatages

Erreur 1 : deviner l’unité avec les seuls chiffres

Le nombre de chiffres est un indice, pas un contrat. Confirmez l’unité source et l’intervalle attendu.

Erreur 2 : ajouter un décalage pour changer de zone

Cette action change l’instant. Conservez l’instant et formatez-le dans la zone cible.

Erreur 3 : utiliser une abréviation comme zone

Des abréviations comme CST peuvent désigner plusieurs lieux ou décalages. Utilisez un identifiant IANA ou un décalage numérique documenté.

Erreur 4 : analyser une date sans zone

Un analyseur peut choisir la zone de l’appareil, UTC ou une autre règle. Exigez un décalage pour les instants et utilisez une zone nommée pour la planification locale.

Erreur 5 : ignorer les trous et chevauchements saisonniers

Certaines heures locales n’existent pas ou apparaissent deux fois. Ajoutez des cas de test et une politique de désambiguïsation.

Erreur 6 : convertir de grandes valeurs avec un flottant

Les entiers de microsecondes, nanosecondes et FILETIME peuvent perdre de la précision. Conservez-les comme chaînes ou entiers arbitraires.

Erreur 7 : faire confiance à l’horloge cliente pour la sécurité

Les horloges des appareils peuvent être fausses ou manipulées. Les protocoles de sécurité exigent une validation serveur, une tolérance d’expiration, une protection contre le rejeu et une source fiable.

Liste de validation

Vérification	Motif
Quelle est l’unité source ?	Une erreur de 1 000 fois crée une date fausse
L’entrée est-elle un entier ou un décimal ?	Les fractions peuvent changer la précision
La valeur peut-elle être négative ?	Certains systèmes refusent les dates avant l’époque
Le type numérique conserve-t-il la valeur ?	L’arrondi peut modifier les unités basses
La sortie utilise-t-elle UTC ou une zone nommée ?	Les étiquettes locales exigent des règles
L’heure locale arrive-t-elle une seule fois ?	L’heure saisonnière crée des trous et chevauchements
Quelle version de la base s’applique ?	Les règles civiles futures peuvent changer
Quelle précision la source a-t-elle mesurée ?	Les chiffres stockés peuvent exagérer la précision

Cette liste transforme un nombre ambigu en conversion documentée. Ajoutez la valeur d’origine, l’unité, l’instant attendu, la zone cible, l’environnement et la version des données de zone aux rapports d’erreur.

Questions fréquentes

Le temps UNIX utilise-t-il toujours les secondes ?

La représentation traditionnelle utilise les secondes. Beaucoup d’API utilisent les millisecondes, microsecondes ou nanosecondes. Lisez le schéma et l’unité.

Le temps UNIX contient-il un fuseau horaire ?

Non. Il identifie un instant relatif à l’époque. Un fuseau nommé intervient pour créer les champs de calendrier locaux.

Quel fuseau l’horodatage 0 utilise-t-il ?

Dans le modèle courant, UNIX 0 correspond à 1970-01-01 00:00:00 UTC. Une vue locale peut afficher une autre date et heure.

Pourquoi mon convertisseur affiche-t-il 1970 ?

La cause la plus courante est une unité incorrecte. Une valeur en secondes traitée comme millisecondes reste proche de l’époque. Confirmez l’unité.

Pourquoi deux convertisseurs diffèrent-ils d’une heure ?

Ils peuvent utiliser des zones, règles saisonnières, versions de base ou politiques d’ambiguïté différentes. Comparez les sorties UTC et les zones nommées.

UTC est-il équivalent à GMT ?

Ils sont souvent interchangeables pour l’affichage quotidien des décalages. Leur histoire technique diffère. Utilisez UTC dans les protocoles explicites.

Puis-je garder seulement un horodatage UTC pour des réunions récurrentes ?

Pas si la réunion doit garder une heure locale. Conservez la zone nommée et la sémantique de répétition. Calculez les instants futurs avec les règles actuelles.

Dois-je utiliser ISO 8601 ou le temps UNIX ?

Choisissez selon l’interface. RFC 3339 est lisible et porte un décalage. Les entiers sont compacts mais exigent une unité documentée. Les deux peuvent identifier le même instant.

Règle finale de conversion

Un horodatage UNIX identifie un instant. Un fuseau explique son affichage sur une horloge locale. Gardez ces concepts séparés.

Confirmez l’unité avant la conversion. Conservez la précision entière. Affichez UTC comme référence stable. Appliquez une zone IANA pour la sortie locale. Testez les limites saisonnières et les dates historiques.