Conversor Timestamp Unix Online Gratuito
Converta timestamps Unix em datas legíveis e datas em timestamps Unix. Detecção automática segundos/milissegundos. 8 fusos horários, ISO 8601.
Timestamp Unix → Data Legível
Data → Timestamp Unix
O que é um Timestamp Unix?
Um timestamp Unix (também chamado epoch time ou POSIX time) é o número de segundos decorridos desde 1 de janeiro de 1970 às 00:00:00 UTC, o epoch Unix. Este ponto de partida foi escolhido pelos primeiros desenvolvedores Unix porque precedia a adoção generalizada dos sistemas Unix. Os timestamps são inteiros independentes do fuso horário, perfeitos para bases de dados, APIs, arquivos de log e tokens JWT.
A época atual corresponde a
O timestamp Unix em tempo real acima, exibido nos formatos de data e hora mais comuns e atualizado a cada segundo.
| — | UTC |
| — | ISO 8601 |
| — | RFC 822 / 1036 / 1123 / 2822 |
| — | RFC 3339 |
Tabela de conversão de tempo Unix
As durações legíveis mais comuns expressas em número de segundos — úteis para calcular expirações, TTLs ou intervalos.
| Tempo legível | Segundos |
|---|---|
| 1 hora | 3600 |
| 1 dia | 86400 |
| 1 semana | 604800 |
| 1 mês (30,44 dias) | 2629743 |
| 1 ano (365,24 dias) | 31556926 |
Timestamp Unix: Segundos vs Milissegundos
A confusão mais comum é saber se um timestamp está em segundos (10 dígitos) ou milissegundos (13 dígitos). A regra: se o valor superar 10¹² quase certamente está em milissegundos.
Usados por PHP time(), Python time.time(), shell Unix date +%s e a maioria dos bancos de dados SQL. Exemplo: 1710508200
1710508200
Usados por JavaScript Date.now(), Java System.currentTimeMillis(), Node.js e a maioria das APIs de navegador. Exemplo: 1710508200000
1710508200000
Casos de Uso Comuns de Timestamps
Por que os desenvolvedores preferem timestamps Unix a strings de data legíveis:
Os JSON Web Tokens usam timestamps Unix em segundos para os claims "issued at" (iat) e "expiration" (exp). São independentes do fuso horário e facilmente comparáveis.
Uma coluna timestamp inteira ordena mais rápido que uma string datetime e é timezone-neutral, eliminando ambiguidades para registros de múltiplas localizações geográficas.
Logs de servidor, tracing distribuído (OpenTelemetry) e pipelines de analytics usam timestamps em milissegundos para correlacionar eventos entre serviços.
Sistemas de cache (Redis, Varnish, CDNs) e respostas de API usam timestamps Unix para Cache-Control max-age, created_at e updated_at.
O que acontece em 19 de janeiro de 2038?
Em 19 de janeiro de 2038, às 03:14:07 UTC, o timestamp Unix ultrapassará o valor máximo que um inteiro com sinal de 32 bits pode armazenar (2.147.483.647). Sistemas que ainda guardam o tempo em 32 bits sofrerão estouro e voltarão a um número negativo, interpretando a data como dezembro de 1901. Antes disso, as aplicações precisarão migrar para timestamps de 64 bits, que ampliam o limite em cerca de 292 bilhões de anos.