Temps (Unix)

L’idée en une phrase

Un horodatage Unix compte les secondes (parfois les millisecondes) écoulées depuis une époque convenue : 1970-01-01T00:00:00Z—minuit UTC le 1er janvier 1970—hors secondes intercalaires dans la définition POSIX habituelle. Cet entier unique stocke un instant sans étiquette de fuseau.

Convertissez un horodatage numérique en date lisible avec l’outil horodatage Unix vers date.

Pourquoi les ingénieurs aiment les secondes d’époque

Les dates civiles exigent calendriers, fuseaux et heure d’été. Les événements instantanés—« cette commande a été payée », « ce certificat expire », « cette ligne de log a été écrite »—sont plus simples comme un compteur monotone depuis une origine fixe. Le temps Unix voyage bien entre langages, bases et API. Trier des horodatages, c’est trier des entiers ; les différences sont des soustractions.

Le prix est la lisibilité humaine : 1710000000 dit peu tant qu’on ne convertit pas. Outils et formateurs de bibliothèque comblent le fossé.

Secondes versus millisecondes versus nanosecondes

Les conventions diffèrent :

Passer des millisecondes à une API qui attend des secondes produit des dates lointaines. Passer des secondes à une API millisecondes atterrit près de 1970. À l’intégration, vérifiez la doc et testez avec un instant connu.

Date.now() en JavaScript renvoie des millisecondes. Beaucoup de frameworks backend utilisent des secondes par défaut. Soyez explicite dans les noms JSON (createdAtSeconds) quand c’est possible.

UTC et affichage local

L’horodatage lui-même est basé UTC. L’afficher à Berlin ou Tokyo applique une conversion de fuseau pour les humains ; l’entier stocké ne change pas. Stockez des instants UTC et localisez aux bords—UI, e-mails, rapports.

Horodatages négatifs et futurs lointains

Les horodatages avant 1970 sont négatifs sur les systèmes qui les supportent. Les dates très lointaines peuvent déborder des entiers signés 32 bits : le classique problème de l’année 2038 pour time_t sur plateformes 32 bits. Le time_t 64 bits moderne repousse le débordement bien au-delà des horizons pratiques à la seconde. Préférez les types 64 bits dans les nouveaux systèmes.

Secondes intercalaires (niveau de conscience)

UTC insère parfois des secondes intercalaires. Le temps Unix POSIX les ignore en général, traitant chaque jour comme 86 400 secondes. Pour les applis métier courantes, c’est suffisant. Pour l’astronomie, les télécoms ou l’horodatage juridique à la seconde autour des sauts, étudiez l’échelle de votre industrie (UTC, TAI, temps GPS) et le support des bibliothèques.

ISO 8601 à côté du temps Unix

Les API acceptent souvent les deux :

• 1710000000
• 2024-03-09T16:00:00Z

Les chaînes ISO 8601 avec Z ou offset numérique communiquent le même instant si le parsing est correct. Le temps Unix est compact ; les chaînes ISO se cherchent bien dans les logs. Beaucoup de systèmes stockent des entiers et émettent de l’ISO en JSON.

Flux de conversion

1. Identifier l’unité (s/ms).
2. Interpréter le nombre comme époque UTC.
3. Formater avec un fuseau explicite pour l’affichage.
4. Aller-retour : formater puis parser, ou reconvertir en époque, pour confirmer l’accord.

La conversion manuelle sans bibliothèque est risquée près des longueurs de mois et années bissextiles—utilisez des bibliothèques testées en production.

Bases de données et indexation

Stockez des entiers d’époque ou des types timestamp natifs normalisés en UTC. Évitez l’heure civile locale sans fuseau si vous visez un instant. Indexer des époques entières est direct ; documentez l’unité dans les commentaires de schéma.

Pour les « dates métier » comme jours de facture, un type date sans heure peut valoir mieux qu’une époque à minuit—politique et juridiction définissent ce que signifie « le jour ».

Journalisation et observabilité

Les processeurs de logs aiment le temps Unix. Corrélez les traces entre services dans le même domaine d’horloge autant que possible. Le décalage d’horloge entre hôtes existe encore—NTP aide—tolérez de petits négatifs dans les durées et préférez les horodatages serveur pour les pistes d’audit autoritaires.

Bugs fréquents

• Décalage d’unité (secondes vs millisecondes).
• Traiter l’époque comme locale en formatant sans Z.
• Mathématiques sur chaînes de dates au lieu d’instants.
• Excel convertit les horodatages avec de mauvaises époques (le jour zéro d’Excel diffère).
• Débordement 32 bits sur systèmes embarqués ou hérités.

Exemple pédagogique

Prenez un horodatage, convertissez en UTC, puis en deux fuseaux civils. Confirmez que les deux chaînes civiles désignent le même instant. Cet exercice construit mieux l’intuition que d’apprendre des formules par cœur.

Utilisez from-unix-timestamp-to-date pour inspecter des valeurs d’API ou de dumps (échantillons non sensibles).

Concepts liés

• Les horloges monotones mesurent le temps écoulé et ne doivent pas reculer ; ce ne sont pas des horodatages Unix et ne doivent pas être persistées comme heure murale.
• Les expressions cron décrivent des plannings civils, pas des époques.
• Les champs notAfter de certificats sont des instants—comparez-les en UTC.

Résumé

Les horodatages Unix encodent des instants comme des comptes depuis 1970-01-01 UTC. Ils simplifient stockage et tri tout en poussant le formatage humain aux bords. Connaissez vos unités, utilisez des types 64 bits, affichez avec des fuseaux explicites, et convertissez avec des outils fiables quand un nombre brut doit devenir une date de calendrier.