Article
Horodatages Unix et expressions cron expliqués
Un horodatage Unix est simplement un entier. Une expression cron est simplement cinq champs. Les deux apparaissent constamment dans le travail côté serveur, et les deux piègent les développeurs de manière prévisible : l'un à cause des fuseaux horaires, l'autre à cause de l'unité.
Ce qu'est un horodatage Unix
Un horodatage Unix compte le nombre de secondes écoulées depuis le 1970-01-01 00:00:00 UTC, un point de référence connu sous le nom d'époque Unix. Cette définition a deux conséquences importantes. D'abord, le comptage est en UTC : aucun fuseau horaire n'est intégré dans le nombre lui-même. La valeur 1718400000 désigne le même instant partout sur Terre, quelle que soit la localisation de la machine qui la stocke. Ensuite, l'époque est définie en secondes, pas dans une autre unité. Une valeur comme 1718400000 représente toujours des secondes depuis minuit UTC le 1er janvier 1970, sauf si un système ou un protocole a fait un choix différent de manière explicite. Les horodatages sont sans fuseau horaire par conception, ce qui les rend utiles pour les journaux, les bases de données et la communication entre systèmes où des horloges dans différentes régions doivent désigner le même instant sans ambiguïté.
Secondes, millisecondes et le problème de l'année 2038
De nombreux environnements d'exécution et API modernes utilisent des millisecondes plutôt que des secondes. La méthode Date.now() de JavaScript retourne des millisecondes, de sorte que 1718400000000 correspond au même instant que la valeur en secondes 1718400000. Lorsque vous recevez un horodatage inconnu, son ordre de grandeur indique l'unité : un nombre à 10 chiffres est presque toujours en secondes ; un nombre à 13 chiffres est presque toujours en millisecondes. Le problème de l'année 2038 découle d'un choix différent : stocker un horodatage en secondes dans un entier signé sur 32 bits. La valeur maximale d'un entier signé 32 bits est 2147483647, ce qui correspond au 2038-01-19 03:14:07 UTC. Après cette seconde, le compteur déborde vers un grand nombre négatif et la date revient en 1901 sur les systèmes qui ne gèrent pas cette limite. Le correctif consiste à utiliser un stockage 64 bits. La plupart des systèmes d'exploitation et des bases de données actuels le font déjà, mais les systèmes embarqués, les équipements réseau et les anciens formats de fichiers dont la largeur de champ a été fixée il y a des décennies restent exposés.
Convertir un epoch en date lisible : l'étape fuseau horaire
Convertir une valeur epoch en date lisible nécessite deux étapes : extraire les composants de la date UTC à partir de l'entier, puis appliquer un décalage UTC pour obtenir l'heure locale. L'horodatage lui-même est en UTC. Lorsque vous cherchez à quelle date correspond 1718325000, la réponse correcte est le 2024-06-14 à 00h30 en UTC. À New York (UTC-4 en été), cette même seconde tombe le 2024-06-13 à 20h30, la veille au soir : la date change, pas seulement l'heure. C'est l'étape dont l'omission produit des résultats incorrects : un développeur enregistre l'horodatage brut en UTC, un outil de reporting l'affiche en heure locale sans conversion, et la date paraît décalée de plusieurs heures ou d'une journée entière. L'outil timestamp-converter de Sunasty gère cela explicitement : vous saisissez une valeur epoch et il affiche la date et l'heure UTC juste à côté de la date et l'heure locales de votre appareil, ce qui rend visible en un coup d'œil un changement de jour comme celui-ci. La conversion s'effectue entièrement dans le navigateur et rien de ce que vous collez n'est envoyé nulle part.
Syntaxe cron : cinq champs, plages, pas et listes
Une expression cron planifie des tâches récurrentes sur les systèmes de type Unix. La syntaxe standard comporte cinq champs séparés par des espaces : minute (0-59), heure (0-23), jour du mois (1-31), mois (1-12), jour de la semaine (0-7, où 0 et 7 représentent tous les deux le dimanche). Un astérisque (*) dans un champ signifie "toute valeur valide". L'expression 30 8 * * 1-5 s'exécute à 08h30 du lundi au vendredi. Les plages utilisent un trait d'union : 1-5 couvre les valeurs 1, 2, 3, 4, 5. Les listes utilisent des virgules : 1,15 signifie le 1er et le 15. Les pas utilisent une barre oblique : */15 dans le champ des minutes signifie toutes les 15 minutes (0, 15, 30, 45). Ces combinateurs peuvent se combiner : 0-30/10 signifie 0, 10, 20, 30. Une chose que cron ne possède pas, c'est un champ de fuseau horaire. Le démon lit l'horloge de la machine sur laquelle il tourne, qui est réglée sur le fuseau horaire local du serveur. Si le serveur est en UTC mais qu'un développeur attend l'heure locale, la tâche se déclenche à la mauvaise heure. La règle pratique est de traiter les expressions cron comme des expressions en heure locale du serveur et de documenter le fuseau horaire du serveur à côté de la ligne cron.
Utiliser le timestamp-converter localement
Le timestamp-converter de Sunasty convertit dans les deux sens : epoch vers date lisible, et date lisible vers epoch. Vous pouvez saisir une valeur en secondes ou en millisecondes ; l'outil détecte l'unité à partir de l'ordre de grandeur. Il affiche le résultat en UTC et dans le fuseau horaire local de votre appareil côte à côte, avec les valeurs brutes en secondes et en millisecondes prêtes à copier. Un bouton Maintenant renseigne l'horodatage actuel en un clic, ce qui est un moyen rapide de connaître l'heure Unix actuelle sans ouvrir un terminal. Il n'y a pas de sélecteur de fuseau horaire séparé : la colonne locale reflète toujours le fuseau horaire actuellement configuré dans votre navigateur. Tout cela fonctionne dans le navigateur. La valeur que vous collez dans le champ est lue par du JavaScript côté client et ne quitte jamais l'appareil.
Outils mentionnés dans cet article
- Convertisseur de timestampConvertissez des timestamps Unix en dates lisibles (UTC + heure locale) et inversement. Détection auto secondes/millisecondes.
- Différence entre datesComptez les jours, semaines, mois et années entre deux dates, entièrement dans votre navigateur, rien n'est envoyé.
- Analyseur d'expression cronAnalysez une expression cron et prévisualisez ses prochaines exécutions. Privé, dans le navigateur.
Questions fréquentes
Pourquoi JavaScript utilise-t-il des millisecondes plutôt que des secondes ?
L'objet Date de JavaScript a été conçu dès le départ pour fonctionner avec une précision inférieure à la seconde, et les millisecondes offrent mille fois plus de résolution que les secondes sans nécessiter de virgule décimale. La contrepartie est que les valeurs sont plus grandes, ce qui explique pourquoi Date.now() produit un nombre à 13 chiffres alors que la plupart des horodatages côté serveur en ont 10.
Tous les serveurs exécutant cron doivent-ils être en UTC ?
Non, mais faire tourner les serveurs en UTC est une pratique courante précisément parce que cela supprime l'ambiguïté. Quand un serveur est en UTC, une expression cron comme 0 2 * * * signifie 02h00 UTC et cette heure est stable toute l'année. Sur un serveur dans un fuseau qui observe l'heure d'été, la même tâche se déclenche à un instant UTC différent en été et en hiver, et peut se déclencher deux fois ou sauter une fois lors du changement d'heure.
Quel type de stockage est sûr pour les horodatages après 2038 ?
Un entier signé sur 64 bits stocke des horodatages en secondes jusqu'à l'année 292277026596, ce qui dépasse largement tout besoin pratique. La plupart des bases de données actuelles stockent les horodatages sous forme de valeurs 64 bits par défaut. Si vous travaillez avec un schéma hérité ou un format de fichier binaire qui utilise des champs 32 bits, migrer vers un stockage 64 bits avant la limite de 2038 est la correction appropriée.