Thema: time
-
Welche Haushaltsaufzeichnungen legen Beginn und Ende eines Stromausfalls im Nachhinein fest, und wie weit haben sie sich unterschieden?
Offene Frage: Nach einem Stromausfall besitzt ein Haushalt mehrere Zeitzeugen des Ereignisses, etwa die Störungsmeldung des Versorgers, ein USV-Protokoll, die Betriebszeit eines Routers, Neustartprotokolle eines Heimservers (die Handbuchseite zu last(1) besagt, dass `last reboot` eine Aufzeichnung der Neustartzeiten liefert, und journalctl kann Boot-Vorgänge mit den Zeitstempeln der ersten und letzten Meldung jedes Boots auflisten), eine batteriegepufferte Uhr, die weiterlief, und eine Netzuhr, die blinkt; welche davon haben Haushalte tatsächlich genutzt, wie weit wichen sie voneinander ab, und welche lieferten die früheste und die späteste Grenze?
-
Ein Schlaf- und Aufwachzeiten-Tagebuch als reines Beobachtungsprotokoll führen
Ein vorgeschlagenes Tagebuchformat, das Lichtausschaltzeit, geschätzten Einschlafzeitpunkt, Aufwachzeit, Aufstehzeit und Tagesereignisse jeden Tag in denselben Feldern festhält, mit vermerkter Zeitzone und jeder Uhrzeitumstellung, sodass eine Reihe Wochen später ohne Neuinterpretation gelesen werden kann; es ist ein persönliches Beobachtungsprotokoll, kein medizinisches Instrument, und es gibt keinen Rat.
-
Locale- und Datumsfallen in coreutils: LC_ALL, Zeichenbereiche und GNU- versus BSD-date
Die Locale ändert stillschweigend die Sortierreihenfolge, was [a-z] erfasst, Dezimaltrennzeichen und das Standard-Datumsformat; Skripte sollten LC_ALL=C (oder C.UTF-8) und TZ explizit setzen, explizite Datumsformate verlangen und GNU-spezifisches date -d oder BSD-spezifisches date -v meiden, solange die Plattform nicht bekannt ist.
-
iCalendar-Einladungen: UID, SEQUENCE und korrekte Zeitzonen
Ein iCalendar-Ereignis wird über UID identifiziert und über SEQUENCE überarbeitet; seine Zeiten sind UTC, lokale Zeit mit einer TZID, die auf eine eingebettete VTIMEZONE verweist, oder frei schwebend. Zonengebundene lokale Zeit für wiederkehrende Termine verwenden, UTC für einmalige zeitzonenübergreifende Ereignisse, und Aktualisierungen sowie Absagen mit der iTIP-METHOD senden, die der empfangende Client erwartet.
-
Für Zeitdauern monotone Uhren verwenden
Lokal verstrichene Zeit und Fristen mit einer monotonen Uhr messen, während für Ereignisaufzeichnungen UTC-Zeitstempel beibehalten werden.
-
Den eigenen Arbeitsweg messen: ein Protokoll für die Zeitmessung von Tür zu Tür
Ein vorgeschlagenes Protokoll zur Zeitmessung eines wiederkehrenden Wegs: feste Start- und Endpunkte, RFC-3339-Zeitstempel mit UTC-Offset an jedem, optionale Abschnittsgrenzen und eine Spalte für Bedingungen (Wochentag, Routenvariante, Wetter, Störung), damit Schwankungen zugeordnet statt bloss erinnert werden können; es wird keine Route empfohlen.
-
Zeitstempel an der Grenze in UTC umwandeln
Mehrdeutige Zeitstempel zurückweisen, zonenbewusste Zeitpunkte in UTC umwandeln und die ursprüngliche Zeitzone bewahren, wenn lokale Planungssemantik wichtig ist.
-
Ein Zeitprotokoll für Paketzustellungen: Bestellung, Versand, Sendungsverfolgung und Haustür-Zeitstempel in einer Zeile, mit dem Scan des Zustelldienstes und der beobachteten Ankunft getrennt gehalten
Ein vorgeschlagenes, reines Erfassungsprotokoll, um den Zeitverlauf jedes Pakets als Zeitstempel im Internet Date/Time Format nach RFC 3339 mit UTC-Offsets festzuhalten, entnommen der Bestellbestätigung, der Versandmeldung, den Sendungsverfolgungsereignissen des Zustelldienstes und der eigenen Notiz des Haushalts zur Ankunft, wobei Zustelldienst, Dienstleistung, Zustellort und jeder Versuch erfasst werden; der Zustell-Scan des Zustelldienstes und die beobachtete Ankunft bilden getrennte Spalten, und es wird weder ein Vergleich zwischen Zustelldiensten noch eine Aussage zur Zustellzeit getroffen.
-
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.
Maschinenlesbar: JSON