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.
-
Locale and date pitfalls in coreutils: LC_ALL, character ranges and GNU versus BSD date
The locale silently changes sort order, what [a-z] matches, decimal separators and the default date format; scripts should set LC_ALL=C (or C.UTF-8) and TZ explicitly, request explicit date formats, and avoid GNU-only date -d or BSD-only date -v unless the platform is known.
-
iCalendar invites: UID, SEQUENCE and getting time zones right
An iCalendar event is identified by UID and revised by SEQUENCE; its times are UTC, local time with a TZID that refers to an embedded VTIMEZONE, or floating. Use zone-anchored local time for recurring meetings, UTC for one-off cross-zone events, and send updates and cancellations with the iTIP METHOD the receiving client expects.
-
Use monotonic clocks for durations
Measure local elapsed time and deadlines with a monotonic clock, while keeping UTC timestamps for event records.
-
Measuring your commute: a door-to-door timing protocol
A proposed protocol for timing a repeated journey: fixed start and end points, RFC 3339 timestamps with UTC offset at each, optional segment boundaries, and a conditions column (weekday, route variant, weather, disruption), so that variation can be attributed rather than remembered; no route is recommended.
-
Convert timestamps to UTC at the boundary
Reject ambiguous timestamps, convert aware instants to UTC and preserve the original timezone when local scheduling semantics matter.
-
A parcel delivery time log: order, dispatch, tracking and door timestamps on one row, with the carrier's scan and the observed arrival kept apart
A proposed record-only protocol for logging each parcel's timeline as timestamps in the RFC 3339 Internet Date/Time Format with UTC offsets, taken from the order confirmation, the dispatch notice, the carrier's tracking events and the household's own note of the arrival, with the carrier, service, delivery place and each attempt recorded; the carrier's delivered scan and the observed arrival are separate columns, and no carrier comparison or delivery-time claim is made.
-
Checking server time synchronisation: timedatectl, chronyc tracking and what to alert on
Clock drift breaks certificate validation, token expiry, log correlation and lock leases silently; on every host check that a time service is running and synchronised, read the offset, stratum and leap status from the daemon, alert on 'not synchronised' and on an offset above a locally chosen bound, and re-check after reboots and image rebuilds.
Lisible par machine : JSON