Tema: time
-
Quais registros domésticos fixam, depois do fato, o início e o fim de uma queda de energia, e quanto eles divergiram?
Pergunta em aberto: após uma queda de energia, a casa tem vários relógios do evento, como o aviso da concessionária, o log de um nobreak (UPS), o uptime do roteador, os registros de reinicialização de um servidor doméstico (a página de manual do last(1) diz que last reboot produz um registro dos horários de reinicialização, e o journalctl pode listar boots com os horários da primeira e da última mensagem de cada um), um relógio a bateria que manteve a hora e um relógio de tomada que pisca; quais deles as famílias realmente usaram, quanto divergiram e quais deram os limites mais antigo e mais recente?
-
Diário de sono e horário de despertar como registro simples de observação
Proposta de formato de diário que registra todos os dias, nos mesmos campos, a hora de apagar a luz, o início estimado do sono, a hora de acordar, a hora de levantar e os eventos do dia, anotando o fuso horário e qualquer mudança de relógio, para que a série possa ser lida semanas depois sem reinterpretação; é um registro pessoal de observação, não uma ferramenta médica, e não dá conselhos.
-
Armadilhas de locale e data no coreutils: LC_ALL, intervalos de caracteres e date do GNU versus BSD
O locale altera silenciosamente a ordem de classificação, o que [a-z] reconhece, os separadores decimais e o formato de data padrão; os scripts devem definir LC_ALL=C (ou C.UTF-8) e TZ explicitamente, pedir formatos de data explícitos e evitar date -d (só GNU) ou date -v (só BSD), a menos que a plataforma seja conhecida.
-
Convites iCalendar: UID, SEQUENCE e como acertar nos fusos horários
Um evento iCalendar é identificado pelo UID e revisado pelo SEQUENCE; seus horários são UTC, hora local com um TZID que aponta para um VTIMEZONE incorporado, ou flutuantes. Use hora local ancorada ao fuso para reuniões recorrentes, UTC para eventos únicos entre fusos e envie atualizações e cancelamentos com o METHOD do iTIP que o cliente receptor espera.
-
Use relógios monotônicos para medir durações
Meça o tempo decorrido local e os prazos com um relógio monotônico, e mantenha timestamps UTC para o registro de eventos.
-
Medir o seu trajeto diário: um protocolo de cronometragem porta a porta
Proposta de protocolo para cronometrar um trajeto repetido: pontos de partida e chegada fixos, timestamps RFC 3339 com deslocamento UTC em cada um, limites de segmento opcionais e uma coluna de condições (dia da semana, variante de rota, clima, perturbações), para que a variação possa ser atribuída a causas em vez de lembrada de memória; nenhuma rota é recomendada.
-
Converter timestamps para UTC na fronteira do sistema
Rejeite timestamps ambíguos, converta instantes com fuso para UTC e preserve o fuso horário original quando a semântica de agendamento local for relevante.
-
Registro de prazos de entrega de encomendas: pedido, envio, rastreamento e chegada na mesma linha, com o scan da transportadora e a chegada observada separados
Protocolo proposto, apenas de registro, para anotar a linha do tempo de cada encomenda em timestamps no formato RFC 3339 com deslocamento UTC, extraídos da confirmação do pedido, do aviso de envio, dos eventos de rastreamento da transportadora e da anotação da própria casa sobre a chegada. Transportadora, serviço, local de entrega e cada tentativa são registrados; o scan de entrega da transportadora e a chegada observada ficam em colunas separadas, e não se faz nenhuma comparação entre transportadoras nem afirmação sobre prazos de entrega.
-
Why NTP still runs inside virtual machines despite guest agents and paravirtual clocks
Virtual machines get time-related help from several layers — kvm-clock, guest agents, Hyper-V integration services — but none of them substitute for an NTP or chrony client running inside the guest. This article explains what each layer actually does and why time sync stays a guest-OS responsibility.
-
Verificar a sincronização de horário em servidores: timedatectl, chronyc tracking e o que monitorar com alertas
O desvio do relógio compromete em silêncio a validação de certificados, a expiração de tokens, a correlação de logs e os leases de locks. Em cada host, confirme que um serviço de horário está ativo e sincronizado, leia offset, stratum e leap status no daemon, alerte para "não sincronizado" e para offset acima de um limite definido localmente, e verifique de novo após reboots e rebuilds de imagem.
Legível por máquina: JSON