Tema: time
-
¿Qué registros domésticos fijan a posteriori el inicio y el fin de un corte de luz, y cuánto han discrepado entre sí?
Pregunta abierta: tras un corte de luz, un hogar dispone de varios «relojes» del suceso —el aviso de la compañía eléctrica, el registro de un SAI, el tiempo de actividad de un router, los registros de reinicio de un servidor doméstico (la página de manual de `last(1)` indica que `last reboot` produce un registro de los momentos de reinicio, y `journalctl` puede listar los arranques con las marcas de tiempo del primer y del último mensaje de cada uno), un reloj con batería que siguió funcionando y un reloj de la red eléctrica que parpadea—; ¿cuáles de ellos han usado realmente los hogares, cuánto discreparon entre sí, y cuáles dieron los límites más tempranos y más tardíos?
-
Llevar un diario de sueño y horas de vigilia como simple registro de observación
Un formato de diario propuesto que registra, con los mismos campos cada día, la hora de apagar la luz, el inicio estimado del sueño, la hora de despertar, la hora de levantarse y los sucesos del día, anotando el huso horario y cualquier cambio de hora, de modo que la serie pueda leerse semanas después sin necesidad de reinterpretarla; es un registro de observación personal, no una herramienta médica, y no da ningún consejo.
-
Trampas de configuración regional y fecha en coreutils: LC_ALL, rangos de caracteres, y GNU frente a BSD date
La configuración regional cambia silenciosamente el orden de ordenación, lo que coincide con [a-z], los separadores decimales y el formato de fecha por defecto; los scripts deben fijar LC_ALL=C (o C.UTF-8) y TZ de forma explícita, solicitar formatos de fecha explícitos, y evitar el date -d exclusivo de GNU o el date -v exclusivo de BSD salvo que se conozca la plataforma.
-
Invitaciones iCalendar: UID, SEQUENCE y cómo gestionar correctamente las zonas horarias
Un evento iCalendar se identifica mediante UID y se revisa mediante SEQUENCE; sus horas pueden ser UTC, hora local con un TZID que remite a un VTIMEZONE incrustado, o flotantes. Usar hora local anclada a una zona para reuniones recurrentes, UTC para eventos puntuales entre husos horarios distintos, y enviar actualizaciones y cancelaciones con el METHOD de iTIP que el cliente receptor espera.
-
Usar relojes monótonos para las duraciones
Medir el tiempo transcurrido local y los plazos con un reloj monótono, y conservar las marcas de tiempo UTC para los registros de eventos.
-
Medición del trayecto habitual: un protocolo de cronometraje puerta a puerta
Un protocolo propuesto para cronometrar un trayecto repetido: puntos de inicio y fin fijos, marcas de tiempo RFC 3339 con desfase UTC en cada uno, límites de tramo opcionales y una columna de condiciones (día de la semana, variante de ruta, clima, interrupción), de modo que la variación pueda atribuirse en lugar de recordarse; no se recomienda ninguna ruta.
-
Convertir las marcas de tiempo a UTC en el límite
Rechazar las marcas de tiempo ambiguas, convertir los instantes con información de zona horaria a UTC, y conservar la zona horaria original cuando importe la semántica de programación local.
-
Un registro de tiempos de entrega de paquetes: pedido, envío, seguimiento y marcas de tiempo en la puerta en una sola fila, manteniendo separados el escaneo del transportista y la llegada observada
Un protocolo propuesto, solo de registro, para anotar la cronología de cada paquete como marcas de tiempo en el formato de fecha y hora de Internet de la RFC 3339 con desfase UTC, tomadas de la confirmación del pedido, el aviso de envío, los eventos de seguimiento del transportista y la propia anotación del hogar sobre la llegada, registrando el transportista, el servicio, el lugar de entrega y cada intento; el escaneo de «entregado» del transportista y la llegada observada son columnas separadas, y no se afirma ninguna comparación entre transportistas ni ningún tiempo de entrega.
-
Por qué NTP sigue ejecutándose dentro de las máquinas virtuales pese a los agentes invitados y los relojes paravirtualizados
Las máquinas virtuales reciben ayuda relacionada con la hora de varias capas (kvm-clock, agentes invitados, servicios de integración de Hyper-V), pero ninguna sustituye a un cliente NTP o chrony dentro del invitado. El artículo explica qué hace realmente cada capa y por qué la sincronización horaria sigue siendo responsabilidad del sistema operativo invitado.
-
Comprobar la sincronización horaria de los servidores: timedatectl, chronyc tracking y qué alertas configurar
La deriva del reloj rompe sin avisar la validación de certificados, la caducidad de tokens, la correlación de logs y los arrendamientos de bloqueos. En cada host, comprueba que haya un servicio de hora activo y sincronizado, lee el offset, el stratum y el estado de leap desde el demonio, alerta cuando no esté sincronizado o el offset supere un límite definido localmente, y repite la comprobación tras reinicios y reconstrucciones de imagen.
Legible por máquina: JSON