Sujet : time
-
Quelles traces domestiques permettent de dater après coup le début et la fin d’une coupure de courant, et avec quels écarts ?
Question ouverte : après une coupure, un foyer dispose de plusieurs traces horaires, comme l’avis du distributeur, le journal d’un onduleur, la durée de fonctionnement d’un routeur, les redémarrages d’un serveur domestique (le manuel last(1) indique que last reboot fournit les heures de redémarrage, et journalctl peut lister les démarrages avec l’horodatage du premier et du dernier message de chacun), une horloge à piles restée à l’heure et une horloge secteur qui clignote. Lesquelles les foyers ont-ils réellement utilisées, de combien divergeaient-elles et lesquelles ont fourni les bornes les plus précoces et les plus tardives ?
-
Tenir un journal des heures de sommeil et de réveil comme simple relevé d’observations
Ce format de journal proposé consigne chaque jour dans les mêmes champs l’extinction des lumières, l’endormissement estimé, le réveil, le lever et les événements de la journée, en indiquant le fuseau horaire et tout changement d’heure, pour permettre de relire la série des semaines plus tard sans la réinterpréter. Il s’agit d’un relevé d’observations personnelles, pas d’un outil médical, et il ne fournit aucun conseil.
-
Pièges de locale et de date dans coreutils : LC_ALL, plages de caractères et date GNU contre BSD
La locale modifie silencieusement l'ordre de tri, ce que [a-z] fait correspondre, les séparateurs décimaux et le format de date par défaut ; les scripts devraient fixer explicitement LC_ALL=C (ou C.UTF-8) et TZ, demander des formats de date explicites, et éviter le date -d propre à GNU ou le date -v propre à BSD, sauf si la plateforme est connue.
-
Invitations iCalendar : UID, SEQUENCE et bien gérer les fuseaux horaires
Un événement iCalendar est identifié par UID et révisé par SEQUENCE ; ses horaires sont en UTC, en heure locale avec un TZID renvoyant à un VTIMEZONE intégré, ou flottants. Utiliser une heure locale ancrée à un fuseau pour les réunions récurrentes, l'UTC pour les événements ponctuels traversant plusieurs fuseaux, et envoyer les mises à jour et annulations avec le METHOD iTIP attendu par le client destinataire.
-
Utiliser des horloges monotones pour les durées
Mesurer le temps écoulé localement et les échéances avec une horloge monotone, tout en conservant des horodatages UTC pour les enregistrements d'événements.
-
Mesurer son trajet domicile-travail : un protocole de chronométrage porte à porte
Un protocole proposé pour chronométrer un trajet répété : des points de départ et d'arrivée fixes, des horodatages RFC 3339 avec décalage UTC à chaque relevé, des limites de segment facultatives, et une colonne de conditions (jour de la semaine, variante d'itinéraire, météo, perturbation), de manière à pouvoir attribuer la variation plutôt que s'en souvenir approximativement ; aucun itinéraire n'est recommandé.
-
Convertir les horodatages en UTC à la frontière
Rejeter les horodatages ambigus, convertir les instants qualifiés en UTC, et préserver le fuseau horaire d'origine lorsque la sémantique de planification locale compte.
-
Un journal des délais de livraison de colis : commande, expédition, suivi et horodatages de porte sur une même ligne, avec le scan du transporteur et l'arrivée observée gardés séparés
Un protocole d'enregistrement proposé, uniquement destiné à la consignation, pour journaliser la chronologie de chaque colis sous forme d'horodatages au format Internet Date/Time de la RFC 3339 avec décalages UTC, tirés de la confirmation de commande, de l'avis d'expédition, des événements de suivi du transporteur et de la note du foyer sur l'arrivée, avec le transporteur, le service, le lieu de livraison et chaque tentative consignés ; le scan « livré » du transporteur et l'arrivée observée sont des colonnes distinctes, et aucune comparaison entre transporteurs ni aucune affirmation sur les délais de livraison n'est avancée.
-
Pourquoi NTP reste nécessaire dans les machines virtuelles malgré les agents invités et les horloges paravirtualisées
Plusieurs couches aident à gérer l'heure dans une machine virtuelle (kvm-clock, agents invités, services d'intégration Hyper-V), mais aucune ne remplace un client NTP ou chrony exécuté dans l'invité. Cet article explique ce que fait réellement chaque couche et pourquoi la synchronisation de l'heure reste du ressort du système invité.
-
Vérifier la synchronisation de l'heure du serveur : timedatectl, chronyc tracking et sur quoi alerter
La dérive d'horloge casse silencieusement la validation des certificats, l'expiration des jetons, la corrélation des journaux et les baux de verrou ; sur chaque hôte, vérifier qu'un service de temps tourne et est synchronisé, lire le décalage, le stratum et le statut de seconde intercalaire auprès du démon, alerter sur « non synchronisé » et sur un décalage dépassant un seuil choisi localement, et revérifier après chaque redémarrage et reconstruction d'image.
Lisible par machine : JSON