Conversor de timestamp Unix (epoch para data)
Cole um timestamp e leia a data, ou escolha uma data e leia o timestamp. Segundos, milissegundos, microssegundos e nanossegundos são detectados pelo número de dígitos, e você pode forçar a interpretação se o número for incomum.
Agora mesmo
- Segundos
- Milissegundos
De timestamp para data
Vírgulas, espaços e sublinhados são ignorados.
De data para timestamp
O que um timestamp Unix realmente conta
Um timestamp Unix é uma contagem de segundos desde 1º de janeiro de 1970 às 00:00:00 UTC, o momento que todo mundo chama de epoch. Não há mais nada dentro dele. Nenhum fuso horário, nenhuma regra de calendário, nenhuma configuração regional: apenas um número sobre uma linha que se estende para a frente e para trás a partir daquele instante.
A parte que pega as pessoas de surpresa são os segundos bissextos. O tempo POSIX define cada dia como exatamente 86.400 segundos, então cerca de duas dúzias de segundos bissextos acrescentados ao tempo civil desde 1972 não aparecem na contagem. Quando um deles é inserido, um timestamp repete um valor ou pula um, dependendo de como o sistema o dilui. A vantagem é que converter um timestamp em data é aritmética pura, sem tabela de consulta. O custo é que um timestamp Unix não consegue nomear um segundo bissexto de jeito nenhum.
Segundos ou milissegundos
As ferramentas Unix, a maioria dos bancos de dados SQL e muitas APIs contam segundos inteiros. JavaScript, Java e tudo o que deriva deles contam milissegundos. Go e alguns sistemas de rastreamento usam nanossegundos. Na documentação, todos são chamados de "o timestamp", e é assim que o bug entra.
O comprimento é a pista mais rápida para qualquer data próxima do presente. Dez dígitos são segundos, treze são milissegundos, dezesseis são microssegundos, dezenove são nanossegundos. Esses comprimentos ficam estáveis por muito tempo: um timestamp em segundos tem dez dígitos desde setembro de 2001 e vai continuar assim até 2286.
O modo de falha é barulhento em uma direção e silencioso na outra. Passe milissegundos para algo que espera segundos e você aterrissa dezenas de milhares de anos no futuro, o que alguém vai perceber. Passe segundos para algo que espera milissegundos e você aterrissa em janeiro de 1970 — uma resposta errada com cara de plausível, que ainda por cima se ordena silenciosamente no topo de todas as listas. Se uma data no seu aplicativo mostra 1970, você errou por um fator de 1000.
O problema de 2038
Um inteiro de 32 bits com sinal acaba em 2.147.483.647 segundos, que são 03:14:07 UTC de 19 de janeiro de 2038. Um segundo depois ele vira um número negativo e a data passa a marcar dezembro de 1901.
O problema não é o seu notebook. O valor de 32 bits sobrevive em firmware embarcado, em código C antigo que nunca foi recompilado, em formatos de arquivo e em colunas de banco de dados: o tipo TIMESTAMP do MySQL ainda está limitado a esse mesmo instante de 2038, enquanto DATETIME não está. Se você guarda a data final de um financiamento imobiliário ou o vencimento de um certificado em um campo de 32 bits, o bug já está nos seus dados.
Um timestamp não tem fuso horário
Vale dizer duas vezes, porque isso causa mais relatórios de incidente do que 2038 jamais vai causar. Um timestamp identifica um instante. O fuso horário é aplicado quando você exibe o valor, não quando o armazena. Duas pessoas lendo o mesmo timestamp em Tóquio e em Lisboa veem relógios de parede diferentes e nenhuma das duas está errada.
O erro clássico é o caminho inverso: pegar os dígitos de um relógio local, chamar mktime ou o equivalente sem o deslocamento, e guardar o resultado. Isso armazena um instante deslocado exatamente por esse valor, e o erro muda duas vezes por ano quando o horário de verão se move. Se o valor veio da agenda de um usuário e não de um relógio, guarde o nome do fuso junto dele: "09:00 em Europe/Madrid" e "um instante" são fatos diferentes.
Onde este conversor para
- Apenas dois fusos. Você recebe o fuso do seu dispositivo e UTC. Não há seletor de fuso, então converter para uma terceira cidade significa fazer a conta de cabeça.
- Entrada abaixo do milissegundo é truncada. As datas do navegador têm resolução de milissegundos, então os três últimos dígitos de um timestamp em microssegundos e os seis últimos de um em nanossegundos são descartados, não arredondados.
- Intervalo. Qualquer coisa além de cerca de 8,64 × 1015 milissegundos a partir do epoch é rejeitada, o que corresponde aos anos -271821 a 275760.
- Datas antigas se desviam. O horário local anterior a 1970 depende de dados históricos de fuso que o seu navegador pode não ter por completo, então horários locais antes de 1970 podem estar errados em uma hora ou em alguns minutos. A linha de UTC está sempre certa.
- O relógio é o do seu dispositivo. Os números de "agora mesmo" são tão precisos quanto a máquina em que você está sentado.
Perguntas frequentes
O que é o epoch do Unix?
Meia-noite UTC de 1º de janeiro de 1970. Foi escolhida como uma data redonda e recente que era conveniente quando a contagem de tempo do Unix foi projetada, sem nenhuma razão mais profunda, e ficou. Timestamps anteriores a ela são negativos.
Como sei se o meu timestamp está em segundos ou em milissegundos?
Conte os dígitos. Para qualquer data próxima de hoje, dez dígitos significam segundos e treze significam milissegundos. Se uma data convertida cai em janeiro de 1970, você passou segundos para algo que esperava milissegundos.
Um timestamp Unix pode ser negativo?
Pode: um valor negativo é essa quantidade de segundos antes de 1970. Esta ferramenta lida com eles, mas muitos programas não: colunas sem sinal, algumas bibliotecas de data e muitas APIs rejeitam qualquer coisa abaixo de zero, então vale testar as datas anteriores a 1970 em vez de supor que funcionam.
Por que o mesmo timestamp mostra um horário diferente na tela do meu colega?
Porque a linha local é exibida no fuso em que o dispositivo está configurado, e o timestamp em si não carrega nenhum. Compare a linha ISO 8601 em UTC: essa é idêntica em qualquer lugar.
O que acontece com os timestamps em 2038?
Contadores de 32 bits com sinal transbordam em 19 de janeiro de 2038 e voltam para 1901. Qualquer coisa que use tempo de 64 bits está segura por mais tempo do que o universo vai se importar, mas valores de 32 bits ainda estão em firmware, em formatos de arquivo antigos e em colunas TIMESTAMP do MySQL.
Última atualização 19 de setembro de 2026