Em resumo: um timestamp Unix é o número de segundos decorridos desde a meia-noite UTC de 1º de janeiro de 1970. Logs e APIs o usam por ser inequívoco e independente de fuso horário. As duas coisas que confundem são distinguir os segundos dos milissegundos e lembrar que o número bruto está sempre em UTC até você convertê-lo para um fuso local.
Ao comparar entradas entre servidores, um simples inteiro é mais fácil de raciocinar que uma data formatada: sem fuso, sem localidade, sem ambiguidade de horário de verão. Mas essa mesma crueza é a razão de um timestamp perdido poder ser mal lido.
Por que os timestamps começam em 1970
A época Unix é a meia-noite UTC de 1º de janeiro de 1970, escolhida pelos primeiros desenvolvedores do Unix nos Bell Labs como ponto de referência simples e fixo. Cada timestamp Unix é apenas a contagem de segundos desde aquele momento, o que torna a aritmética — «quanto tempo entre estes dois eventos?» — uma simples subtração.
Segundos ou milissegundos?
É o erro mais comum ao ler logs. Regra prática: se o valor tem mais de 11 dígitos (maior que cerca de 10¹¹), quase certamente está em milissegundos. Um timestamp atual em segundos gira em torno de 1,7 bilhão (dez dígitos); o mesmo instante em milissegundos, cerca de 1,7 trilhão (treze dígitos). Passe um valor em milissegundos a um analisador de segundos e você cairá dezenas de milhares de anos no futuro.
O timestamp está sempre em UTC
Um timestamp Unix codifica um instante absoluto, não uma hora local de relógio. Para exibi-lo a um humano você aplica um fuso: o mesmo número é «14:30 em Londres» e «09:30 em Nova York». Converter nos dois sentidos de forma limpa significa ser explícito quanto ao fuso: um bom conversor usa a base padrão de fusos IANA e a API Intl.DateTimeFormat para que o deslocamento (incluído o horário de verão) fique correto para aquela data.
ISO 8601 para tudo que você armazena ou compartilha
Quando um timestamp precisa ser legível por humanos e ainda seguro para a máquina, use ISO 8601: 2024-03-15T14:30:00.000Z. O T separa data e hora e o Z indica UTC. Ele ordena corretamente como texto simples e tira a dúvida segundos-vs-milissegundos de quem ler depois.
A nota sobre 2038
Sistemas que armazenam o timestamp como inteiro com sinal de 32 bits estouram em 19 de janeiro de 2038. A maioria das plataformas modernas migrou para o tempo de 64 bits, mas vale saber ao encontrar um sistema antigo ou uma coluna de banco de dados de largura fixa.
Um fluxo prático
- Copie o valor bruto do seu log ou da resposta da API.
- Cole-o no Conversor de Timestamp, que detecta automaticamente segundos vs milissegundos e mostra a data no fuso escolhido.
- Converta os dois eventos que compara para o mesmo fuso (ou mantenha ambos em UTC) antes de subtrair.
- Armazene ou compartilhe o resultado como ISO 8601 para não reintroduzir ambiguidade. Combine com o Contador de Caracteres se estiver limpando um trecho de log para um chamado.
Erros comuns a evitar
- Misturar segundos e milissegundos na mesma comparação.
- Supor que um timestamp bruto já está em hora local.
- Comparar dois eventos exibidos em fusos diferentes.
- Usar campos de tempo de 32 bits de largura fixa que não sobrevivem a 2038.