Conversor Epoch/Unix Online
Converta timestamps Unix para datas legíveis e vice-versa. Essencial para depurar APIs e logs.
Para que serve
Timestamps Unix na hora
Segundos e milissegundos
Detecta automaticamente se o timestamp está em segundos (10 dígitos) ou milissegundos (13 dígitos).
100% privado
A conversão acontece no seu navegador usando a API Date nativa do JavaScript. Sem servidores.
Vários formatos
Exibe o resultado em ISO 8601, UTC, data local e formato relativo (há X dias).
Instantâneo
A conversão é imediata. Também mostra o timestamp atual atualizado em tempo real.
Como funciona
Três passos, sem complicação
Insira o timestamp ou a data
Cole um timestamp Unix (em segundos ou milissegundos) ou insira uma data no formato ISO 8601 para converter na direção oposta.
Selecione o fuso horário
Escolha seu fuso horário ou UTC para ver a data local correta. Timestamps Unix são sempre UTC internamente.
Copie o resultado
Obtenha a data formatada em vários formatos (ISO 8601, UTC, local) ou o timestamp numérico. Um clique para copiar.
Perguntas frequentes
Ficou com dúvidas?
O epoch Unix (também chamado de Unix time ou POSIX time) é o número de segundos decorridos desde 1 de janeiro de 1970 às 00:00:00 UTC, excluindo segundos bissextos. Essa data de referência foi escolhida porque o Unix foi desenvolvido no final dos anos 1960 e era preciso um ponto de partida conveniente. O Unix time é contínuo, uniforme e independente de fuso horário, o que o torna ideal para armazenar e comparar instantes em sistemas distribuídos.
Os sistemas Unix clássicos (C, Python datetime, bancos SQL) usam segundos. Ambientes JavaScript/Node.js, Java (System.currentTimeMillis()) e muitas APIs modernas usam milissegundos. Um timestamp em segundos tem 10 dígitos (por exemplo, 1704067200 para 1 de janeiro de 2024), enquanto em milissegundos tem 13 dígitos (1704067200000). Alguns sistemas usam microssegundos (16 dígitos) ou nanossegundos (19 dígitos) para medições de alta precisão.
O problema Y2K38 (também chamado de Problema do Ano 2038 ou Bug do Milênio Unix) ocorrerá em 19 de janeiro de 2038 às 03:14:07 UTC. Naquele momento, o timestamp Unix armazenado como inteiro de 32 bits com sinal (int32) atingirá seu valor máximo (2.147.483.647) e causará overflow, voltando a um número negativo que os sistemas interpretarão como 13 de dezembro de 1901. Sistemas que usam int64 (inteiros de 64 bits) não terão esse problema até o ano 292.277.026.596.
Os timestamps Unix têm vantagens técnicas claras sobre datas formatadas: são um número simples (fácil de comparar, ordenar e serializar), não têm ambiguidade de fuso horário (representam sempre o mesmo instante UTC), não têm ambiguidade de formato (MM/DD/AAAA vs DD/MM/AAAA), ocupam menos espaço (8 bytes como int64 contra 24+ bytes como string ISO) e são mais eficientes para operações de intervalo em índices de banco de dados.
Os timestamps Unix são sempre UTC — representam o mesmo instante independentemente de onde você esteja. O fuso horário só importa ao converter um timestamp para uma representação legível (data e hora locais) ou ao criar um timestamp a partir de uma data local. Um erro comum é ignorar o fuso horário ao fazer parse de datas e assumir o horário local: isso causa erros de mais ou menos N horas dependendo do offset do fuso do sistema, erros difíceis de detectar pois os testes geralmente rodam em UTC.
Unix time: o relógio universal dos sistemas computacionais
O Unix time é o padrão de fato para representar instantes temporais em sistemas computacionais. Sua elegância está na simplicidade: um único inteiro que cresce monotonicamente, sem ambiguidade de formato, fuso horário ou calendário. Ele foi definido na especificação POSIX e adotado por todos os sistemas operacionais derivados do Unix (Linux, macOS, BSD) e pela maioria das linguagens de programação modernas. O POSIX.1-2008 o define formalmente como o número de segundos desde o epoch Unix, com a peculiaridade notável de que os segundos bissextos não são contados.
No ecossistema de bancos de dados, os timestamps Unix são onipresentes. O PostgreSQL tem o tipo TIMESTAMP que internamente armazena microssegundos desde o epoch Unix. O MySQL oferece as funções UNIX_TIMESTAMP() e FROM_UNIXTIME(). O MongoDB armazena datas como milissegundos desde o epoch no seu tipo Date. O Redis usa timestamps Unix para expiração de chaves (EXPIREAT). Logs de sistema do Apache, Nginx e syslog frequentemente incluem timestamps Unix para facilitar o processamento com ferramentas como awk, grep e scripts shell.
O problema Y2K38 é o equivalente moderno do Y2K original: sistemas que armazenam timestamps como int32 com sinal vão causar overflow em 19 de janeiro de 2038. Embora a maioria dos sistemas modernos já use int64, o problema persiste em sistemas embarcados, firmwares antigos e código legado. A migração para int64 é a solução padrão. O Convertir.ai mostra quanto tempo falta para o Y2K38 e permite verificar se um timestamp específico é anterior ou posterior a essa data crítica.