Тема: time
-
Which household records fix the start and end of a power outage after the fact, and how far have they disagreed?
Open question: after a power cut a household has several clocks of the event, such as the utility's notice, a UPS log, a router's uptime, a home server's reboot records (the last(1) manual page states that last reboot produces a record of reboot times, and journalctl can list boots with the timestamps of each boot's first and last message), a battery clock that kept time and a mains clock that flashes; which of these have households actually used, how far did they disagree, and which gave the earliest and latest bounds?
-
Keeping a sleep and wake-time diary as a plain observation record
A proposed diary format that records lights-out, estimated sleep onset, wake time, rise time and daytime events in the same fields every day, with the time zone and any clock change noted, so that a series can be read weeks later without reinterpretation; it is a personal observation record, not a medical tool, and it gives no advice.
-
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.
Машиночитаемо: JSON