Unix time représente un instant comme un nombre d’unités écoulées depuis le début de 1970 en UTC. Cette idée simple permet de comparer des événements entre machines sans transporter le nom du mois, la langue ou le fuseau horaire dans chaque valeur. Les timestamps expirent des tokens, ordonnent des logs, déclenchent des jobs et stockent des audits. Pourtant, le nombre ne résout pas à lui seul la complexité du temps.

Un instant n’est pas une date affichée

Un timestamp indique une position sur une ligne temporelle commune. Il ne contient pas la façon de l’afficher pour un utilisateur. Le même instant peut apparaître comme lundi soir à Paris et mardi matin ailleurs. L’interface transforme l’instant en date locale seulement au moment de présenter l’information.

Ce découpage est utile. Les erreurs arrivent lorsque l’on stocke une heure locale comme si elle était déjà un instant global.

Secondes et millisecondes se mélangent facilement

Le timestamp Unix classique compte des secondes. JavaScript et de nombreuses API utilisent des millisecondes. Interpréter l’un comme l’autre produit des dates proches de 1970 ou dans un futur absurde. Le bug est visible, mais seulement si les champs et les tests vérifient les unités.

Les noms devraient être explicites: created_at_ms, expires_at_seconds ou une chaîne ISO 8601. Deviner l’unité par le nombre de chiffres peut aider en debug, pas définir un contrat.

L’horloge système est une mesure imparfaite

Les horloges dérivent, se corrigent par synchronisation réseau et peuvent sauter. Le wall clock sert à enregistrer ce qui s’est passé dans le monde partagé. Pour mesurer une durée, il est dangereux, car il peut reculer.

Les timeouts et mesures de durée doivent utiliser une horloge monotone. Elle n’a pas de sens calendrier, mais elle avance de manière cohérente dans un processus. Les deux horloges répondent à des questions différentes.

Les leap seconds rappellent les détails

Le temps civil a dû gérer des leap seconds liées à la rotation irrégulière de la Terre. Les systèmes Unix ne les représentent pas toujours comme des instants distincts. Certains répètent, d’autres lissent, d’autres suivent la plateforme.

La plupart des applications métier peuvent accepter le comportement standard. Les systèmes scientifiques, financiers ou distribués à haute précision doivent connaître leur source de temps et leur politique de synchronisation.

La précision affichée doit être honnête

Stocker des nanosecondes ne signifie pas que l’événement a été mesuré à la nanoseconde. Les types de base, flottants, formats externes et systèmes 32 bits ont tous des limites. Le problème de 2038 rappelle que le range lui aussi dépend de la représentation.

Le contrat doit indiquer précision réelle et règles de troncature ou d’arrondi. Sinon, deux services peuvent ordonner différemment des événements proches.

Tous les concepts temporels ne sont pas des instants

La création d’une commande est un instant. “Tous les lundis à 9 h à Lyon” est une règle locale. Un anniversaire est une date de calendrier. Une durée de cache est un intervalle. Les mettre tous dans un timestamp unique perd du sens.

Pour un événement récurrent, stockez heure locale, règle de répétition et fuseau IANA. Chaque occurrence future se calcule avec les règles de calendrier appropriées.

Les types de base de données encodent des hypothèses

Un type timestamp peut normaliser en UTC ou garder une date locale selon le moteur. La timezone de session peut influencer lecture et écriture. Une colonne appelée date ne suffit pas à expliquer ce qu’elle contient.

Documentez si la valeur est un instant, une date locale, une date-heure locale ou une durée. Cette précision évite des migrations qui réinterprètent silencieusement les données.

Les logs doivent être comparables

Dans un système distribué, des logs en fuseaux locaux différents ralentissent les incidents. UTC, précision connue, format uniforme et trace ID rendent l’analyse possible. Le timestamp aide à situer; il ne prouve pas toujours la causalité.

Pour les jobs, séparez scheduled time, enqueue time, start time et finish time. Cela montre où le retard est apparu.

Unix time est un dénominateur commun

Il fonctionne très bien pour des instants techniques avec unité claire. Il ne remplace pas les calendriers humains, fuseaux, règles récurrentes ni durées monotones. Le bon modèle commence par la signification, puis choisit la représentation.

Les contrats d’API doivent nommer la précision

Si un producteur envoie des microsecondes et qu’un consommateur ne garde que les secondes, deux événements proches peuvent changer d’ordre. Le contrat doit dire si les chiffres supplémentaires sont refusés, arrondis ou tronqués. Cette règle devrait être la même dans API, base et logs.

Les exemples de documentation doivent contenir un offset, une précision et une valeur réelle. Un seul exemple précis révèle souvent les hypothèses cachées mieux qu’une phrase générale sur les timestamps.

Les imports historiques demandent prudence

Des données anciennes peuvent mélanger secondes, millisecondes et dates locales. Avant une migration, il faut échantillonner, détecter les unités et conserver le contexte d’origine. Une conversion globale trop confiante peut déplacer des années d’événements.

Cette discipline évite les bugs qui n’apparaissent qu’au changement de fuseau, lors d’une correction d’horloge ou après intégration avec une autre plateforme.