Um conversor de timestamp Unix teria me poupado horas em um projeto de cliente. Um número de 13 dígitos quebrou o login porque os claims exp do JWT estavam em milissegundos, mas o servidor esperava segundos. Cole qualquer timestamp aqui e veja a data e a hora em UTC, GMT ou no seu horário local.
Conversor de Timestamp Unix Converta epoch em segundos, milissegundos, microssegundos ou nanossegundos para uma data legível, e vice-versa. O texto substitui os campos. Datas sem fuso usam o horário do seu navegador. Digite um timestamp ou uma data acima para ver o resultado Referência rápida: timestamps importantes Toque em uma linha para carregá-la no conversor Compartilhar ou copiarTimestamp Data (UTC) Momento 0 1970-01-01 00:00:00 Época Unix (tempo 0) 946684800 2000-01-01 00:00:00 Ano 2000 1700000000 2023-11-14 22:13:20 1,7 bilhão de segundos 1777118400 2026-04-25 12:00:00 Exemplo do guia 1800000000 2027-01-15 08:00:00 1,8 bilhão de segundos 2147483647 2038-01-19 03:14:07 Limite de 32 bits (ano 2038)
A ferramenta lê timestamps de 10 e 13 dígitos, além de microssegundos e nanossegundos. Isso cobre a saída POSIX de linguagens de backend, JavaScript, Java e message brokers. Eu uso quase todo dia para conferir colunas de banco de dados, linhas de log, respostas de API e eventos de analytics.
Todo valor conta a partir de 1970-01-01 00:00:00 UTC, sem calendários nem fusos envolvidos. Abaixo você encontra uma explicação direta sobre epoch, a sintaxe de conversão nas principais linguagens e uma referência rápida para gatilhos de agendamento e cabeçalhos de expiração de cache em qualquer web app ou app mobile.
O que é um timestamp Unix (tempo epoch)?
Um timestamp Unix não tem fuso horário. Muita gente acha que tem, e essa ideia gera muitos bugs. Ele é só a contagem de segundos desde a época Unix e mostra o mesmo número em um servidor em Tóquio e em um notebook em Lisboa.
O ponto de partida é 1º de janeiro de 1970, à meia-noite GMT. Em ISO 8601, isso fica 1970-01-01T00:00:00Z. O tempo Unix 0 marca exatamente esse instante, e você também vai ouvir os nomes tempo POSIX ou simplesmente epoch.
Um detalhe me surpreendeu no começo: o tempo Unix ignora os segundos bissextos. Cada dia UTC conta exatamente 86.400 segundos. A conta fica simples, mesmo que se afaste um pouco dos relógios atômicos.
A quantidade de dígitos mostra a precisão:
- 10 dígitos são segundos
- 13 dígitos são milissegundos
- 16 dígitos são microssegundos
- 19 dígitos são nanossegundos
Eu conto os dígitos antes de qualquer coisa. Isso economiza mais tempo do que qualquer ferramenta.
Computadores guardam o tempo assim porque um número inteiro é fácil de ordenar, comparar e acompanhar. Bancos de dados, APIs e agendadores reservam horários com números simples. Aplicações distribuídas evitam discussões sobre qual relógio está certo, seja no servidor ou no lado do cliente.
Decisões antigas ainda causam problemas. Muitos sistemas gravaram o tempo como inteiros de 32 bits com sinal, que acabam em 19 de janeiro de 2038. Esse é o problema do ano 2038, e ele já afeta qualquer app que calcula datas com anos de antecedência.
Como Converter um Timestamp Unix em Data
A maioria das conversões erradas começa com um palpite errado sobre a unidade. Por isso, o conversor verifica o tamanho do valor colado. Um valor de 10 dígitos é lido como segundos, um de 13 dígitos como milissegundos, e você pode trocar a unidade manualmente.
- Cole o valor. Pode ser um JWT exp, um número de uma linha do banco ou algo copiado de uma consulta de log.
- Escolha o fuso de exibição. Selecione UTC, seu horário local ou qualquer outro fuso. Isso muda só a forma de mostrar a data, não o timestamp.
- Leia o resultado. Você recebe uma string ISO 8601, o horário local e uma frase relativa como há 3 horas ou daqui a 2 dias. Eu colo a versão ISO nos tickets de bug porque o offset vai junto.
- Faça o caminho inverso. Preencha os campos de data e hora ou cole uma data em texto, e a ferramenta devolve o tempo Unix no formato que você precisa.
Timestamp Unix em segundos ou milissegundos
O pior bug de timestamp que já corrigi jogou a expiração de um cache cerca de 54.000 anos para o futuro. Alguém passou milissegundos para uma função que esperava segundos. Ninguém percebeu por semanas.
Estes dois valores apontam para o mesmo instante, 25 de abril de 2026, às 12:00 UTC:
- 1777118400 (10 dígitos, segundos)
- 1777118400000 (13 dígitos, milissegundos)
Só a unidade muda. Ferramentas POSIX e a maioria das linguagens de backend usam segundos por padrão. JavaScript e Java usam milissegundos. Message brokers variam, e alguns registram microssegundos ou até nanossegundos.
Por que Timestamps Unix São Salvos em UTC
Em todo projeto em que trabalho, defendo salvar o tempo em UTC. Guarde segundos ou milissegundos com base em UTC e converta para o horário local só quando uma pessoa precisar ver.
O motivo é prático. O relógio do dispositivo pode estar errado, e as regras de horário de verão mudam de país para país. Sistemas que salvam horário local acabam com uma hora duplicada todo ano, e os relatórios deixam de bater.
Quando você precisa de texto em vez de número, use ISO 8601. O Z no final significa +00:00. Um offset como +02:00 indica duas horas à frente do UTC. Então 2026-04-25T12:00:00Z e 2026-04-25T14:00:00+02:00 descrevem exatamente o mesmo instante.
Antes de comparar strings ISO, converta todas para o mesmo fuso. Texto com offsets diferentes fica na ordem errada quando você ordena.
UTC vs Horário Local: Mesmo Instante, Exibição Diferente
2026-04-25T12:00:00Z e 2026-04-25T14:00:00+02:00 são o mesmo instante. O offset +02:00 muda só o que o relógio mostra.
Minha regra é simples: salve momentos em UTC e mostre horário local para as pessoas. Misturar os dois na mesma coluna do banco é o jeito mais rápido de um relatório contar uma hora duas vezes.
Quando Desenvolvedores Usam um Conversor Epoch
Converter timestamp não é um trabalho empolgante, mas ocupa boa parte das minhas horas de depuração. É aqui que ele mais aparece:
- Rastreamento de logs: alinhe linhas de log de dois serviços convertendo ambos para UTC.
- Depuração de cron: confira se os gatilhos rodaram no horário local ou UTC. Essa diferença explica a maioria dos jobs “perdidos”.
- Consultas no banco: transforme colunas salvas em segundos em datas antes de filtrar.
- Respostas de API: decodifique respostas e claims exp do JWT para achar tokens expirados.
- Comparações precisas: alinhe eventos de analytics no nível do milissegundo.
- Cabeçalhos de cache: confirme quando um cache expira e leia o prazo como tempo relativo.
Tabela de Referência: Tempo Epoch em Segundos
Deixe esta tabela à mão ao definir TTLs, duração de cookies ou validade de tokens.
| Período | Segundos | Observação |
| 1 hora | 3.600 | Exato |
| 1 dia | 86.400 | Ignora horário de verão |
| 1 semana | 604.800 | 7 × 86.400 |
| 1 mês | 2.629.743 | Média de 30,44 dias |
| 1 ano | 31.556.926 | Ano trópico, 365,24 dias |
| 1 ano (juliano) | 31.557.600 | 365,25 dias |
Meses e anos não têm duração fixa. Não use 2.629.743 fixo no código para ciclos de cobrança. Use as funções de calendário da sua linguagem.
O Problema do Ano 2038 Explicado
Esse não é um problema distante. Se você gera parcelas de financiamento, apólices ou certificados válidos depois de 2038, essas datas já passam do limite hoje.
Um inteiro de 32 bits com sinal chega no máximo a 2.147.483.647. Esse valor cai em 19 de janeiro de 2038, às 03:14:07 UTC. Um segundo depois, o número estoura e volta para dezembro de 1901.
Sistemas de 64 bits resolvem isso. Linguagens modernas e a maioria dos bancos de dados já guardam o tempo em inteiros de 64 bits, que duram centenas de bilhões de anos. Não é preciso um padrão novo, só mais espaço.
O risco real está em aplicações antigas, firmware embarcado e colunas TIMESTAMP legadas do MySQL que ainda param em 2038-01-19. Eu passo uma data de teste em 2040 por todo o sistema para pegar falhas cedo.
Exemplos de Código de Timestamp Unix em 15 Linguagens
Cada linguagem trata o epoch de um jeito, e a armadilha entre segundos e milissegundos aparece de novo. Todos os exemplos usam 1800000000 segundos, que equivalem a 15 de janeiro de 2027, às 08:00 UTC, para você conferir o resultado.
| Linguagem | Tempo Epoch Atual | Epoch para Data Legível |
| Python | import time; time.time() | time.ctime(1800000000) |
| PHP | time() | date(‘Y-m-d H:i:s’, 1800000000) |
| JavaScript | Math.floor(new Date().getTime() / 1000) | new Date(1800000000 * 1000).toLocaleString() |
| Java | System.currentTimeMillis() / 1000 | new SimpleDateFormat(“yyyy-MM-dd HH:mm:ss”).format(new java.util.Date(1800000000L * 1000)) |
| Ruby | Time.now.to_i | Time.at(1800000000) |
| Go | time.Now().Unix() | time.Unix(1800000000, 0) |
| C# | DateTimeOffset.Now.ToUnixTimeSeconds() | DateTimeOffset.FromUnixTimeSeconds(1800000000).LocalDateTime |
| PostgreSQL | SELECT EXTRACT(EPOCH FROM now()); | SELECT TO_TIMESTAMP(1800000000); |
| MySQL | SELECT UNIX_TIMESTAMP(NOW()); | SELECT FROM_UNIXTIME(1800000000); |
| SQL Server | SELECT DATEDIFF(SECOND, ‘1970-01-01’, GETUTCDATE()); | SELECT DATEADD(SECOND, 1800000000, ‘1970-01-01’); |
| SQLite | SELECT unixepoch(); | SELECT datetime(1800000000, ‘unixepoch’, ‘localtime’); |
| Shell Linux | date +%s | date -d @1800000000 |
| macOS | date +%s | date -j -r 1800000000 |
| PowerShell | [DateTimeOffset]:: NowoUnixTimeSeconds() | [DateTimeOffset]:: FromUnixTimeSeconds(1800000000).LocalDateTime |
| Excel | =(NOW()-25569)*86400 | =A1/86400+25569 (formate como data) |
Algumas observações de projetos reais:
- JavaScript: os métodos de Date retornam milissegundos, então divida por 1000 e use Math.floor quando a API pedir segundos. A referência de Date no MDN explica os detalhes.
- C# em .NET antigo: use new DateTime(1970, 1, 1, 0, 0, 0, DateTimeKind.Utc).AddSeconds(1800000000), porque os métodos auxiliares não existem nessas versões.
- Python: datetime.fromtimestamp() retorna horário local, a menos que você passe um fuso. A documentação oficial do datetime explica o argumento tz.
- Excel: as datas contam dias a partir de 1900. Divida por 86.400 e some 25.569, o número de série de 1º de janeiro de 1970. NOW() usa o horário local da sua máquina, não UTC. No Excel em português, a função se chama AGORA().
- SQLite: unixepoch() exige a versão 3.38 ou mais recente.
Timestamp Unix vs ISO 8601: Qual Formato Salvar
Um timestamp Unix nem sempre é a melhor escolha. Eu decido com base em quem vai ler o valor: uma máquina, uma pessoa ou os dois.
| Formato | Exemplo | Melhor Para |
| Segundos Unix | 1777118400 | Logs de backend, JWT exp, POSIX time(), TTLs do Redis |
| Milissegundos Unix | 1777118400000 | JavaScript Date.now(), Java System.currentTimeMillis() |
| ISO 8601 | 2026-04-25T12:00:00Z | APIs REST, JSON, GraphQL, arquivos de log |
| ISO 8601 com offset | 2026-04-25T14:00:00+02:00 | Agendamentos para usuários, convites de calendário |
| RFC 2822 | Sat, 25 Apr 2026 12:00:00 GMT | Cabeçalhos de e-mail, HTTP Date, Last-Modified |
| Só a data | 2026-04-25 | Aniversários, feriados |
Valores só de data não servem para contas com epoch. Salve um aniversário como meia-noite UTC e ele aparece um dia antes para metade dos seus usuários.
O fator 1000 é o erro clássico. Leia 1700000000 como milissegundos e você cai em janeiro de 1970. Leia como segundos e é novembro de 2023. Quando a data convertida sai décadas erradas, confira a unidade primeiro.
Interpretar uma data em texto sem offset faz o sistema adivinhar usando o fuso local do servidor. É por isso que datas formatadas mudam durante a troca do horário de verão. Mantenha o UTC como fonte da verdade.
Eventos recorrentes são a exceção. Uma reunião semanal às 9h precisa seguir as regras de horário de verão da região dela, então eu salvo a regra local junto com o valor UTC.
Para prazos de segurança, como expiração de tokens e senhas de uso único, confie no relógio do servidor, nunca no dispositivo. Eu deixo uma tolerância de 30 a 60 segundos, porque o relógio do celular desvia mais do que parece.
Como Ler um Timestamp Unix em uma Resposta de API
Imagine que um endpoint retorna este JSON:
json
{ “id”: 42, “createdAt”: 1777118400, “expiresAt”: 1777204800 }
Os dois valores têm 10 dígitos, então são segundos Unix. O registro foi criado em 25 de abril de 2026, às 12:00 UTC, e expira exatamente 24 horas depois. Se a expiração já passou, o registro está vencido. Se está no futuro, continua válido.
Backends muito baseados em JavaScript costumam enviar milissegundos. Nunca presuma. Leia a documentação da API antes de tratar qualquer valor como segundos.
Perguntas Frequentes
O conversor Aceita segundos e milissegundos?
Sim. Cole um timestamp de 10 dígitos em segundos ou de 13 dígitos em milissegundos, e a ferramenta detecta sozinha. Para o caminho inverso, informe ano, mês, dia, hora, minuto e segundo.
Quais Resultados Posso Copiar?
Você copia qualquer resultado com um clique: o timestamp em segundos, o valor em milissegundos, a string ISO 8601, UTC, horário local e tempo relativo.
Qual fuso horário o conversor mostra?
Ele mostra UTC e lê seu horário local pelo navegador. Você pode trocar a exibição para outro fuso sem mexer nas configurações do sistema.
O que é tempo epoch, em termos simples?
O tempo epoch é um único número que conta segundos ou milissegundos desde 1970-01-01 00:00:00 UTC. Ele marca um instante exato, não importa onde você esteja.
Por que alguns timestamps têm 10 dígitos e outros 13?
Um timestamp de 10 dígitos conta segundos. Um de 13 dígitos conta milissegundos. O Date.now() do JavaScript retorna milissegundos, enquanto a maioria dos backends em Python, PHP e Go usa segundos.
O Que Significa UTC?
UTC significa Tempo Universal Coordenado, o relógio de referência global. Ele nunca muda com o horário de verão, por isso bancos de dados, APIs e logs confiam nele.
¿Por qué el JavaScript usa milisegundos?
O JavaScript construiu o objeto Date com milissegundos para ter mais precisão no navegador. Date.now() e new Date().getTime() retorna milissegundos, enquanto a maioria das outras linguagens usa segundos. Essa diferença causa a maior parte dos bugs de fator 1000.
Como converto um timestamp Unix em data no código?
No JavaScript, multiplique os segundos por 1000 e passe o resultado para new Date(). No Python, use datetime.fromtimestamp(). Ou cole o valor neste conversor e veja a resposta na hora.
Timestamps Unix Podem Estourar?
Timestamps de 32 bits com sinal estouram em 2038-01-19, o chamado problema do ano 2038. Linguagens e bancos modernos usam inteiros de 64 bits, que empurram esse limite para centenas de bilhões de anos.
O que o conversor mostra depois que coloco um timestamp?
Você vê a data e a hora no seu fuso local, em UTC e em qualquer outro fuso escolhido, além dos valores em segundos, milissegundos e ISO 8601.
Posso Converter uma Data Normal em Timestamp Unix?
Sim. Abra a aba “Data e hora para Unix”, informe a data e a hora, e você recebe o timestamp em segundos e em milissegundos.
Um Timestamp Unix Muda Entre Fusos Horários?
Não. O número é idêntico em qualquer lugar. Só a data e a hora exibidas mudam conforme o fuso em que você vê.