Timestamps Unix explicados - epoch, ISO-8601 e fusos horários

Publicado a 19 de abril de 2026

---

Um timestamp Unix codifica tempo como inteiro - segundos (10 dígitos) ou milissegundos (13 dígitos) desde 1 de janeiro de 1970 UTC. ISO 8601 e RFC 2822 adicionam strings legíveis com fuso horário para intercâmbio de dados. Este guia explica como converter entre os três formatos, evitar o erro off-by-1000 e lidar com transições DST corretamente.

Epoch Unix: segundos desde 1970-01-01 UTC

O timestamp Unix - também chamado "tempo epoch" - é o número de segundos que decorreram desde 00:00:00 UTC em 1 de janeiro de 1970. Esse ponto de referência é arbitrário mas universal; todos os sistemas derivados de Unix (Linux, macOS, Android, iOS) e quase todas as linguagens de programação seguem o tempo internamente como contagem a partir desse momento.

Um valor atualizado: 1776495426 traduz para 2026-04-18 12:17:06 UTC. Não há fuso horário codificado no próprio número - é sempre UTC - o que é tanto uma força (sem ambiguidade quando dois sistemas comparam timestamps) como uma armadilha (o que quer que converta o número numa string legível tem de escolher um fuso, e normalmente escolhe o local).

Segundos vs milissegundos: a primeira fonte de confusão

JavaScript, Java e a maioria das bibliotecas padrão de linguagens modernas usam por defeito milissegundos desde o epoch, não segundos. Esse mesmo momento - 2026-04-18 12:17:06 UTC - é 1776495426 em segundos (10 dígitos) mas 1776495426000 em milissegundos (13 dígitos). Uma regra rápida para verificar a sanidade de um timestamp que recebeu:

• 10 dígitos → segundos (linha de comandos Unix, PHP, Python time.time(), Go).
• 13 dígitos → milissegundos (JavaScript Date.now(), Java System.currentTimeMillis(), a maioria das APIs JSON).
• 16 ou 19 dígitos → microssegundos ou nanossegundos (telemetria especializada e tempo científico).

Um valor de 10 dígitos em segundos interpretado como milissegundos renderiza como uma data em 1970 (50+ anos demasiado cedo). Um valor de 13 dígitos em milissegundos interpretado como segundos renderiza como uma data ~56,000 DC. Ambos os erros são instantaneamente visíveis assim que o timestamp é convertido - use Convert Milliseconds to Date para verificar a sanidade ou Get Current Time in Milliseconds para comparar com o agora.

ISO 8601: o formato de intercâmbio legível

ISO 8601 é um formato data-hora legível para humanos com o qual as máquinas também concordam. A forma canônica é: 2026-04-18T12:17:06.520Z. Partes:

• Data: 2026-04-18 (AAAA-MM-DD, sempre nesta ordem).
• Separador: T (letra T literal entre data e hora).
• Hora: 12:17:06.520 (HH:MM:SS.sss, 24 horas).
• Fuso horário: Z para UTC, ou um offset como +07:00 / -05:30 para outras zonas.

ISO 8601 é inequívoco (sem confusão regional de datas como 04-18 vs 18-04), ordenável como string simples (a ordem lexical corresponde a ordem cronológica quando o fuso é o mesmo) e suportado por todos os parsers modernos. Se controla a API que está a construir, prefira strings ISO 8601 em vez de números raw de epoch Unix - carregam o fuso explicitamente, o que remove uma classe inteira de bugs.

RFC 2822: o formato legado de email e HTTP

RFC 2822 (é o HTTP-date quase idêntico do RFC 7231) parece Sat, 18 Apr 2026 12:17:06 +0000. É o formato que verá em cabeçalhos Date: de email, cabeçalhos HTTP Last-Modified, e algumas APIs web mais antigas. É legível mas não ordenável como string simples (o prefixo do dia da semana quebra a ordenação lexical), portanto os sistemas devolvem cada vez mais ISO 8601 ao lado ou em vez de RFC 2822. Quando precisa de gerar RFC 2822 manualmente, use uma biblioteca em vez de construir a string a mão - o nome do dia da semana e a abreviatura do mês são sensíveis a locale e fáceis de errar.

UTC vs hora local: a raiz da maioria dos bugs de timestamp

Timestamps de epoch Unix são sempre UTC; strings ISO 8601 podem ser UTC (Z) ou qualquer offset; RFC 2822 carrega quase sempre um offset. Mas quando um programa mostra um timestamp, normalmente converte para o fuso horário local da máquina que está a mostrar.

Isto é bom para um único utilizador mas causa caos em três cenários:

• Partilhar um timestamp no chat. "O deploy aconteceu às 14:00" é ambíguo - 14:00 de quem? Cole o valor ISO 8601 (2026-04-18T14:00:00+07:00) ou indique explicitamente o fuso horário.
• Logs de vários servidores. Defina todos os servidores em UTC. Sempre. Agregadores de logs e ferramentas de resposta a incidentes assumem UTC; misturar fusos horários em logs é a forma mais rápida de atribuir mal uma cadeia causa-efeito.
• Horários virados para o utilizador. Armazene a hora do evento em UTC (ou no fuso horário fonte do evento com offset explícito) e converta no momento da exibição. Não armazene "19h" sem fuso horário; "19h" na sessão de um utilizador pode ser 16h para outro.

Três armadilhas comuns (e como apanha-las)

1. Timestamps inteiros vs strings em JSON. O JSON.parse do JavaScript produzirá fielmente um número para 1776495426520 - mas se a API devolveu o mesmo timestamp como string "1776495426520", qualquer código downstream a fazer aritmética nele coercera silenciosamente. Verifique sempre o tipo antes de passar para new Date().

2. Mês 0-11 em JavaScript Date. new Date(2026, 3, 18) é 18 de abril de 2026, não 18 de março de 2026. O mês é indexado a 0 mas o dia e o ano são indexados a 1. Prefira o construtor ISO 8601 (new Date("2026-04-18")) que segue a numeração natural.

3. Transições de horário de verão. Na noite de "avançar a hora", às 2:30 da manhã hora local não existem; na noite de "atrasar a hora", às 1:30 da manhã acontecem duas vezes. Se o seu sistema armazena strings de hora local, esses momentos criam timestamps impossíveis ou duplicados. O armazenamento UTC elimina o problema; bibliotecas de Date como Luxon ou date-fns-tz tratam a conversão explicitamente.

Ferramentas relacionadas

• Convert Milliseconds to Date - cole um timestamp, obtenha datas formatadas UTC e local.
• Get Current Time in Milliseconds - leitura epoch ao vivo atualizada a cada segundo.
• MD5 Converter - hash de uma string para checksums ou chaves de deduplicação.
• JSON Parser - inspeciona respostas de API que contém campos de timestamp.
• Current millis - timestamp Unix ao vivo em milissegundos - guia complementar mostrando como ler o valor epoch em tempo real.
• Este número longo é milissegundo ou segundo? - use isto quando receber um número desconhecido e precisar confirmar a precisão antes de analisar.

← Voltar a Utility Tools

Last reviewed: 2026-07-01

FreetoolOnline editorial team