Timestamps Unix explicados - epoch, ISO-8601 e fusos horarios
Cada log de servidor, linha de base de dados e resposta de API na internet codifica "quando algo aconteceu" num de quatro formatos: o epoch Unix (segundos ou milissegundos), ISO 8601 ou RFC 2822. Se ja colou um timestamp no Slack apenas para discutir em que fuso horario estava, este guia e para si. Cobre o que cada formato realmente codifica, como converter entre eles e as tres armadilhas que apanham ate programadores experientes.
Epoch Unix: segundos desde 1970-01-01 UTC
O timestamp Unix - tambem chamado "tempo epoch" - e o numero de segundos que decorreram desde 00:00:00 UTC em 1 de janeiro de 1970. Esse ponto de referencia e arbitrario mas universal; todos os sistemas derivados de Unix (Linux, macOS, Android, iOS) e quase todas as linguagens de programacao seguem o tempo internamente como contagem a partir desse momento.
Um valor atualizado: 1776495426 traduz para 2026-04-18 12:17:06 UTC. Nao ha fuso horario codificado no proprio numero - e sempre UTC - o que e tanto uma forca (sem ambiguidade quando dois sistemas comparam timestamps) como uma armadilha (o que quer que converta o numero numa string legivel tem de escolher um fuso, e normalmente escolhe o local).
Segundos vs milissegundos: a primeira fonte de confusao
JavaScript, Java e a maioria das bibliotecas padrao de linguagens modernas usam por defeito milissegundos desde o epoch, nao segundos. Esse mesmo momento - 2026-04-18 12:17:06 UTC - e 1776495426 em segundos (10 digitos) mas 1776495426000 em milissegundos (13 digitos). Uma regra rapida para verificar a sanidade de um timestamp que recebeu:
- 10 digitos → segundos (linha de comandos Unix, PHP, Python
time.time(), Go). - 13 digitos → milissegundos (JavaScript
Date.now(), JavaSystem.currentTimeMillis(), a maioria das APIs JSON). - 16 ou 19 digitos → microssegundos ou nanossegundos (telemetria especializada e tempo cientifico).
Um valor de 10 digitos em segundos interpretado como milissegundos renderiza como uma data em 1970 (50+ anos demasiado cedo). Um valor de 13 digitos em milissegundos interpretado como segundos renderiza como uma data ~56,000 DC. Ambos os erros sao instantaneamente visiveis assim que o timestamp e 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 intercambio legivel
ISO 8601 e um formato data-hora legivel para humanos com o qual as maquinas tambem concordam. A forma canonica e: 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 horario:
Zpara UTC, ou um offset como+07:00/-05:30para outras zonas.
ISO 8601 e inequivoco (sem confusao regional de datas como 04-18 vs 18-04), ordenavel como string simples (a ordem lexical corresponde a ordem cronologica quando o fuso e o mesmo) e suportado por todos os parsers modernos. Se controla a API que esta a construir, prefira strings ISO 8601 em vez de numeros 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 (e o HTTP-date quase identico do RFC 7231) parece Sat, 18 Apr 2026 12:17:06 +0000. E o formato que vera em cabecalhos Date: de email, cabecalhos HTTP Last-Modified, e algumas APIs web mais antigas. E legivel mas nao ordenavel como string simples (o prefixo do dia da semana quebra a ordenacao 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 mao - o nome do dia da semana e a abreviatura do mes sao sensiveis a locale e faceis de errar.
UTC vs hora local: a raiz da maioria dos bugs de timestamp
Timestamps de epoch Unix sao 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 horario local da maquina que esta a mostrar.
Isto e bom para um unico utilizador mas causa caos em tres cenarios:
- Partilhar um timestamp no chat. "O deploy aconteceu as 14:00" e ambiguo - 14:00 de quem? Cole o valor ISO 8601 (
2026-04-18T14:00:00+07:00) ou indique explicitamente o fuso horario. - Logs de varios servidores. Defina todos os servidores em UTC. Sempre. Agregadores de logs e ferramentas de resposta a incidentes assumem UTC; misturar fusos horarios em logs e a forma mais rapida de atribuir mal uma cadeia causa-efeito.
- Horarios virados para o utilizador. Armazene a hora do evento em UTC (ou no fuso horario fonte do evento com offset explicito) e converta no momento da exibicao. Nao armazene "19h" sem fuso horario; "19h" na sessao de um utilizador pode ser 16h para outro.
Tres armadilhas comuns (e como apanha-las)
1. Timestamps inteiros vs strings em JSON. O JSON.parse do JavaScript produzira fielmente um numero para 1776495426520 - mas se a API devolveu o mesmo timestamp como string "1776495426520", qualquer codigo downstream a fazer aritmetica nele coercera silenciosamente. Verifique sempre o tipo antes de passar para new Date().
2. Mes 0-11 em JavaScript Date. new Date(2026, 3, 18) e 18 de abril de 2026, nao 18 de marco de 2026. O mes e indexado a 0 mas o dia e o ano sao indexados a 1. Prefira o construtor ISO 8601 (new Date("2026-04-18")) que segue a numeracao natural.
3. Transicoes de horario de verao. Na noite de "avancar a hora", as 2:30 da manha hora local nao existem; na noite de "atrasar a hora", as 1:30 da manha acontecem duas vezes. Se o seu sistema armazena strings de hora local, esses momentos criam timestamps impossiveis ou duplicados. O armazenamento UTC elimina o problema; bibliotecas de Date como Luxon ou date-fns-tz tratam a conversao 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 deduplicacao.
- JSON Parser - inspeciona respostas de API que contem campos de timestamp.
Why trust these tools
- Ten-plus years of web tooling. The freetoolonline editorial team has shipped browser-based utilities since 2015. The goal has never changed: get you to a working output fast, without an install.
- Truly in-browser - no upload. Every file-processing tool on this site runs in your browser through modern Web APIs (File, FileReader, Canvas, Web Audio, WebGL, Web Workers). Your photo, PDF, audio, or text never leaves your device.
- No tracking during tool use. Analytics ends at the page view. The actual input you paste, drop, or capture is never sent to any server and never written to any log.
- Open-source core components. The processing engines underneath (libheif, libde265, pdf-lib, terser, clean-css, ffmpeg.wasm, and others) are public and audit-able. We link to each one in its tool page's footer.
- Free, with or without ads. All tools are fully functional without sign-up. The Disable Ads button in the header is always available if you need a distraction-free run.