Um timestamp Unix parece simples: uma contagem de segundos desde 1º de janeiro de 1970, 00:00:00 UTC. Na prática, porém, dois eventos podem compartilhar o mesmo timestamp, o relógio da máquina pode recuar e dois servidores podem discordar sobre o horário. Até um relógio que informa nanossegundos pode errar por vários milissegundos. No Linux, esse número aparentemente banal abre caminho para problemas de engenharia nada triviais. Vamos examinar onde a medição de tempo costuma falhar.

Relógio de parede e relógio monotônico: a escolha que evita bugs

Imagine que você começa a baixar um arquivo. Seu programa registra o horário de início, baixa o arquivo e registra o horário de término.

Mas, no meio do caminho, o relógio do sistema é corrigido. Agora seu programa acha que o download terminou antes de começar.

O arquivo viajou no tempo? Claro que não. O problema é usar um relógio que pode ser ajustado para medir tempo decorrido.

O Linux oferece relógios diferentes para tarefas diferentes. Dois dos mais úteis são:

  • CLOCK_REALTIME representa o horário de parede atual.
  • CLOCK_MONOTONIC fornece um relógio que avança de forma constante para medir tempo decorrido.

O relógio de parede pode saltar para frente ou para trás quando o sistema o ajusta. Um relógio monotônico não anda para trás, embora sua taxa ainda possa ser ajustada no Linux.

A mesma distinção aparece em Python:

import time
print("Wall clock:", time.time())
print("Monotonic clock:", time.monotonic())

Os valores têm significados diferentes. time.time() retorna tempo baseado na época Unix. time.monotonic() usa um ponto de referência específico do relógio, então seu valor bruto não é um timestamp de calendário.

A lição: use o relógio de parede para responder “quando isso aconteceu?”. Use um relógio monotônico para responder “quanto tempo levou?”.

NTP e a correção do relógio do sistema

Seu computador tem um relógio, mas isso não significa que ele sempre saiba a hora correta.

Relógios de hardware sofrem deriva. Alguns andam um pouco rápido; outros, um pouco devagar. Deixe duas máquinas rodando tempo suficiente e seus relógios podem discordar.

É aí que entra o NTP, o Network Time Protocol. Ele ajuda computadores a sincronizar seus relógios com fontes externas de tempo.

Mas sincronização não é mágica. Atrasos de rede, fontes de tempo defeituosas e correções de relógio podem afetar o resultado. Dependendo da configuração, o software de sincronização pode ajustar gradualmente a taxa do relógio ou dar um salto para frente ou para trás.

Em uma distribuição Linux típica baseada em systemd, você pode inspecionar a configuração de tempo com:

timedatectl status

A saída varia conforme a distribuição e a configuração. Procure pelo relógio do sistema e pelo status de sincronização de tempo. O comando é específico para sistemas baseados em systemd.

A lição: um timestamp diz o que um relógio informou. Ele não diz automaticamente o quão perto essa leitura estava da hora correta.

Fusos horários, horário de verão e agendamentos

Suponha que você agende um script para rodar todos os dias às 9h.

A solução óbvia parece ser esperar 86.400 segundos (24 horas) após cada execução.

Só que dias de calendário local nem sempre contêm 86.400 segundos decorridos. Transições de horário de verão podem fazer um dia local durar 23 ou 25 horas. Historicamente, segundos bissextos também complicaram a relação entre UTC e uma contagem simples de segundos.

E fusos horários não são apenas deslocamentos fixos em relação ao UTC. Governos podem mudar suas regras, e o software precisa de informações atualizadas para lidar com essas mudanças.

Experimente estes dois comandos no seu sistema Linux:

TZ=UTC date
TZ=Asia/Kolkata date

Esses comandos exibem a data e a hora atuais de acordo com o fuso horário especificado.

Para um evento único, um timestamp Unix pode ser exatamente o que você precisa. Mas considere este requisito:

Rodar este script toda segunda-feira às 9h em Nova York.

Um timestamp sozinho não captura essa intenção. Você precisa de uma regra de recorrência, de um horário local e de um identificador de fuso horário.

Para saber mais sobre essas regras, explore a IANA Time Zone Database.

A lição: um ponto no tempo e uma regra sobre o calendário local são duas coisas diferentes.

Ordenação de eventos entre máquinas

Aqui a coisa fica realmente interessante.

O servidor A registra um evento em 12:00:00.100.

O servidor B registra outro evento em 12:00:00.080.

Qual evento aconteceu primeiro?

Você pode concluir que o evento do servidor B veio primeiro porque seu timestamp é menor.

Mas e se o relógio do servidor B estiver adiantado em relação ao do servidor A?

Você acabou de encontrar um dos problemas fundamentais dos sistemas distribuídos: timestamps sozinhos não estabelecem de forma confiável a ordem dos eventos entre máquinas.

A sincronização de relógios pode ajudar, mas não garante que todo servidor informe exatamente a mesma hora.

Sistemas distribuídos usam outros mecanismos para lidar com a ordenação dos eventos. Dependendo do problema, isso pode incluir números de sequência, relógios lógicos, posições de log de banco de dados ou protocolos de coordenação.

Lembre-se de que dois eventos podem compartilhar o mesmo timestamp mesmo quando ambos os relógios funcionam perfeitamente. Eles podem simplesmente ter ocorrido dentro da mesma resolução de relógio.

A lição: não presuma que o menor timestamp sempre identifica o evento mais antigo quando os registros vêm de máquinas diferentes.

Identidade e tempo em bancos de dados

Imagine que você está construindo um serviço de pagamentos. Você decide usar o timestamp Unix atual como chave primária de cada pagamento.

No começo, tudo parece bem.

Então dois clientes fazem pagamentos no mesmo segundo. As duas requisições geram o mesmo timestamp. As duas tentam inserir uma linha com a mesma chave primária.

Uma inserção falha.

Você troca de segundos para milissegundos. As colisões ficam menos prováveis, mas ainda são possíveis. Passar para nanossegundos também não garante unicidade como num passe de mágica.

O problema não é necessariamente precisão insuficiente. É que você pediu a um relógio uma garantia para a qual ele não foi projetado.

Um design melhor separa identidade de tempo:

CREATE TABLE payments (
id UUID PRIMARY KEY,
created_at TIMESTAMPTZ NOT NULL,
amount NUMERIC NOT NULL
);

Este exemplo no estilo PostgreSQL usa um UUID para identificar cada pagamento e um timestamp para registrar quando ele foi criado. Sua aplicação ou seu banco de dados ainda precisa gerar o UUID.

Cada campo tem uma responsabilidade clara.

A lição: um timestamp descreve quando algo aconteceu. Um identificador distingue esse algo de outras coisas.

Laboratório rápido no terminal

Chega de teoria. Abra um terminal e rode estes comandos:

# What time does your system report?
date
# What time is it in UTC?
date -u
# What is the current Unix timestamp?
date +%s
# What does the system report about time synchronization?
timedatectl status

O último comando é destinado a sistemas Linux baseados em systemd. Os demais comandos estão amplamente disponíveis em sistemas do tipo Unix, embora as opções possam variar entre implementações.

Agora, se você tiver Python 3 instalado, rode:

import time
print("Wall clock:", time.time())
print("Monotonic clock:", time.monotonic())
print("Performance counter:", time.perf_counter())

Essas três chamadas têm propósitos diferentes:

  • time.time() fornece o tempo de parede baseado na época.
  • time.monotonic() é útil para medir tempo decorrido.
  • time.perf_counter() é projetado para medir desempenho de curta duração.

Saída de exemplo:

Wall clock: 1792679694.0232277
Monotonic clock: 445.774622884
Performance counter: 445.774647309

O relógio monotônico e o contador de desempenho não fornecem timestamps de calendário comuns. Não compare seus valores brutos com timestamps Unix.

Para os detalhes subjacentes do Linux, leia o manual de clock_gettime().

O que fica desta investigação

Você começou com um número contando segundos desde 1970. Agora já encontrou relógios imprecisos, sincronização de tempo, transições de horário de verão, ordenação de eventos em sistemas distribuídos e identidade em bancos de dados.

A parte surpreendente não é que a medição de tempo seja complicada. É que tanto software depende dela tratando-a como um problema resolvido.

E há mais para explorar: segundos bissextos, o problema do ano 2038, precisão de timestamps e as formas sutis como linguagens de programação lidam com datas anteriores à época Unix.