Conversor de Timestamp

Continuar na ferramenta

Mais páginas desta ferramenta

converter timestamp unix de log para data

Converter Unix timestamp para data, segundos, milissegundos e fuso

Um número solto num log, numa coluna de banco ou na resposta de uma API não diz sozinho se é segundos ou milissegundos, nem em qual fuso ele deveria ser lido. O timestamp em si é sempre relativo a UTC, sem fuso embutido; é a interpretação que decide se 1700000000 vira uma hora da manhã ou da noite.

Segundos, milissegundos e o fuso que muda a leitura

Este conversor decide sozinho a unidade quando você não informa: valores cujo módulo passa de 1×10¹² são lidos como milissegundos, valores abaixo disso como segundos. A fronteira existe porque milissegundos desde 1970 já ultrapassam 1×10¹² por volta de setembro de 2001, então qualquer timestamp de um sistema atual em milissegundos cai acima da linha, e qualquer timestamp em segundos de uma data razoável cai abaixo. É uma heurística, não uma regra do formato: nada no número em si marca a unidade.
Bancos de dados e logs tendem a escolher um lado por convenção, não por padrão universal: colunas Unix de PostgreSQL e MySQL (EXTRACT(EPOCH FROM ...), UNIX_TIMESTAMP()) devolvem segundos, enquanto Date.now() do JavaScript e System.currentTimeMillis() do Java devolvem milissegundos. Um timestamp de 10 dígitos geralmente é segundos, um de 13 dígitos geralmente é milissegundos, mas "geralmente" para de valer perto da virada de década, quando os dois formatos têm quantidades de dígitos parecidas por um tempo.
O timestamp Unix em si não carrega fuso, mas o valor "local" que este conversor mostra sim: ele usa o fuso IANA resolvido pelo navegador de quem está lendo, então a mesma entrada em segundos produz uma hora local diferente em São Paulo e em Lisboa, embora o instante UTC seja idêntico nos dois casos. Sistemas de 32 bits com sinal, ainda comuns em firmware e bancos de dados antigos, armazenam o timestamp num inteiro que estoura em 19 de janeiro de 2038 às 03:14:07 UTC, quando o valor máximo representável (2.147.483.647 segundos) é ultrapassado.

Três timestamps, três leituras

Timestamp de 10 dígitos, segundos

Entrada: 1700000000
Saída esperada: 2023-11-14T22:13:20.000Z

Abaixo de 1×10¹², o conversor assume segundos por padrão; é o formato que UNIX_TIMESTAMP() do MySQL devolve.

O mesmo instante, agora em milissegundos

Entrada: 1700000000000
Saída esperada: 2023-11-14T22:13:20.000Z

Três zeros a mais, o mesmo instante: é o formato que Date.now() do JavaScript devolve, e o conversor troca automaticamente de unidade porque o valor passa de 1×10¹².

O limite de 32 bits com sinal

Entrada: 2147483647
Saída esperada: 2038-01-19T03:14:07.000Z

É o maior número que um inteiro de 32 bits com sinal representa; um segundo depois, um sistema legado que ainda usa esse tipo de dado estoura de volta para uma data em 1901.

FAQ da ferramenta completa

O que é Unix timestamp?

É o número de segundos (ou milissegundos, em JavaScript) decorridos desde 1 de janeiro de 1970 às 00:00:00 UTC. Também chamado de Epoch time ou POSIX time, é o formato universal para representar instantes de tempo em sistemas computacionais.

Como distingo segundos de milissegundos num timestamp?

Por que o horário exibido difere da minha hora local?

Qual é o maior timestamp Unix representável?

Por que o JavaScript usa milissegundos e não segundos?

O que é ISO 8601?

Quando devo usar timestamp vs. string ISO?

Este conversor tem fuso horário correto para o Brasil?

Perguntas frequentes

Como saber se um timestamp de log está em segundos ou milissegundos?

Conte os dígitos: 10 dígitos costuma ser segundos (cobrindo datas até o ano 2286), 13 dígitos costuma ser milissegundos. Este conversor automatiza isso com o corte em 1×10¹², mas a contagem manual de dígitos já resolve a dúvida na maioria dos logs, porque a diferença de três ordens de grandeza raramente é ambígua.

Por que a mesma entrada mostra horas diferentes em "local" e "UTC"?

Porque o timestamp Unix é sempre relativo a UTC e não carrega fuso nenhum; "local" é uma conversão feita depois, usando o fuso de quem está lendo a tela. O instante no tempo é idêntico nos dois casos, só a hora do relógio de parede muda conforme o fuso.

O bug de 2038 afeta sistemas modernos?

Não os que usam inteiros de 64 bits para armazenar o timestamp: 64 bits com sinal só estouram bilhões de anos no futuro, então Linux, macOS e a maioria dos bancos de dados atuais já migraram. O risco real está em firmware embarcado, protocolos antigos e código de 32 bits que nunca foi atualizado.

Próximos passos

Continuar na ferramenta

Abrir ferramenta completa

converter timestamp unix de log para data

Converter Unix timestamp para data, segundos, milissegundos e fuso

Segundos, milissegundos e o fuso que muda a leitura

Este conversor decide sozinho a unidade quando você não informa: valores cujo módulo passa de 1×10¹² são lidos como milissegundos, valores abaixo disso como segundos. A fronteira existe porque milissegundos desde 1970 já ultrapassam 1×10¹² por volta de setembro de 2001, então qualquer timestamp de um sistema atual em milissegundos cai acima da linha, e qualquer timestamp em segundos de uma data razoável cai abaixo. É uma heurística, não uma regra do formato: nada no número em si marca a unidade.

Bancos de dados e logs tendem a escolher um lado por convenção, não por padrão universal: colunas Unix de PostgreSQL e MySQL (EXTRACT(EPOCH FROM ...), UNIX_TIMESTAMP()) devolvem segundos, enquanto Date.now() do JavaScript e System.currentTimeMillis() do Java devolvem milissegundos. Um timestamp de 10 dígitos geralmente é segundos, um de 13 dígitos geralmente é milissegundos, mas "geralmente" para de valer perto da virada de década, quando os dois formatos têm quantidades de dígitos parecidas por um tempo.

O timestamp Unix em si não carrega fuso, mas o valor "local" que este conversor mostra sim: ele usa o fuso IANA resolvido pelo navegador de quem está lendo, então a mesma entrada em segundos produz uma hora local diferente em São Paulo e em Lisboa, embora o instante UTC seja idêntico nos dois casos. Sistemas de 32 bits com sinal, ainda comuns em firmware e bancos de dados antigos, armazenam o timestamp num inteiro que estoura em 19 de janeiro de 2038 às 03:14:07 UTC, quando o valor máximo representável (2.147.483.647 segundos) é ultrapassado.

Três timestamps, três leituras

Timestamp de 10 dígitos, segundos

Entrada: 1700000000
Saída esperada: 2023-11-14T22:13:20.000Z

Abaixo de 1×10¹², o conversor assume segundos por padrão; é o formato que UNIX_TIMESTAMP() do MySQL devolve.

O mesmo instante, agora em milissegundos

Entrada: 1700000000000
Saída esperada: 2023-11-14T22:13:20.000Z

Três zeros a mais, o mesmo instante: é o formato que Date.now() do JavaScript devolve, e o conversor troca automaticamente de unidade porque o valor passa de 1×10¹².

O limite de 32 bits com sinal

Entrada: 2147483647
Saída esperada: 2038-01-19T03:14:07.000Z

É o maior número que um inteiro de 32 bits com sinal representa; um segundo depois, um sistema legado que ainda usa esse tipo de dado estoura de volta para uma data em 1901.

FAQ da ferramenta completa

O que é Unix timestamp?

Como distingo segundos de milissegundos num timestamp?

Por que o horário exibido difere da minha hora local?

Qual é o maior timestamp Unix representável?

Por que o JavaScript usa milissegundos e não segundos?

O que é ISO 8601?

Quando devo usar timestamp vs. string ISO?

Este conversor tem fuso horário correto para o Brasil?

Perguntas frequentes