Conversor de Timestamp Unix Gratuito

Converta entre timestamps Unix e datas legíveis por humanos.

Nenhum dado sai do seu dispositivo

Timestamp Unix Atual

Timestamp → Data

Data → Timestamp

O Que é um Timestamp Unix?

Um timestamp Unix (também chamado de tempo de época ou tempo POSIX) é o número de segundos que se passaram desde 1 de janeiro de 1970, 00:00:00 UTC. É uma forma simples e independente de fuso horário para representar um ponto no tempo e é amplamente utilizado em programação, bancos de dados, APIs e logs de servidor.

Por exemplo, o timestamp 1700000000 representa 14 de novembro de 2023 às 22:13:20 UTC. O JavaScript usa timestamps em milissegundos (multiplique por 1000), enquanto a maioria dos outros idiomas e APIs usa segundos.

Perguntas Frequentes

Quais formatos de data posso inserir?

Você pode inserir datas na maioria dos formatos padrão: ISO 8601 (2025-12-31T23:59:59Z), strings de data comuns (Dec 31, 2025 11:59 PM) ou formatos simples como 2025-12-31 23:59:59. O conversor usa o analisador de datas integrado do seu navegador.

Detecta segundos vs. milissegundos automaticamente?

Sim. Se o timestamp for maior que 1 trilhão, o conversor o trata como milissegundos. Caso contrário, trata como segundos. Ambos os formatos são exibidos na tabela de resultados.

O que é o problema do Ano 2038?

Sistemas que armazenam timestamps Unix como inteiros assinados de 32 bits sofrerão overflow em 19 de janeiro de 2038 às 03:14:07 UTC. Sistemas modernos usam inteiros de 64 bits, que podem representar datas bilhões de anos no futuro. Esta ferramenta usa o tipo Number do JavaScript, que lida com timestamps muito além de 2038.

Por que 1º de janeiro de 1970?

Um timestamp Unix é uma contagem inteira de segundos decorridos desde a epoch Unix, 00:00:00 UTC de quinta-feira, 1º de janeiro de 1970. É um escalar único que nomeia, sem ambiguidade, um instante no tempo, independentemente de calendário e de fuso horário: o mesmo número nomeia o mesmo instante esteja você em Tóquio ou em Toronto.

A escolha de 1970 foi um tanto arbitrária, mas não aleatória. A primeira edição do UNIX Programmer's Manual (novembro de 1971) definia o tempo do sistema como o número de tiques de relógio a 60 Hz desde 1971-01-01. Com um inteiro de 32 bits sem sinal contando a 60 Hz, o sistema só dava conta de uns 2,26 anos antes do overflow, um problema que ficou óbvio rápido. Na preparação da segunda edição em 1972, a equipe de Ken Thompson e Dennis Ritchie passou a contar segundos desde 1970-01-01: inteiros de 32 bits com sinal contando segundos durariam cerca de 68 anos, bem além da vida profissional dos engenheiros que escreviam o código, e o Ano-Novo mais recente antes do início do projeto facilitava a aritmética. Não houve voto de comitê nem processo de padronização à la IANA. A escolha pegou porque o Unix saiu com ela, e quando cem milhões de máquinas já contavam a partir daquele instante, nenhum substituto era viável.

POSIX (1988) codificou a epoch de 1970 sob a IEEE Std 1003.1 como «Seconds Since the Epoch». Hoje, a mesma epoch sustenta C/C++ time_t, Python time.time(), Ruby Time.now.to_i, JavaScript e Java (em milissegundos, ver abaixo), timestamps de sistema de arquivos no Linux/macOS, cabeçalhos de bloco do Bitcoin e do Ethereum, e claims JWT iat/exp/nbf. Alguns sistemas usam epochs distintas (Windows FILETIME conta tiques de 100 ns desde 1601-01-01, .NET DateTime tiques desde 0001-01-01), mas o tempo Unix é a língua franca de qualquer coisa que cruze fronteira de SO ou de linguagem.

Segundos vs milissegundos, o bug mais comum

POSIX define o timestamp como segundos desde a epoch. Toda lib C, todo interpretador Python, todo runtime Ruby/Go/Rust/Elixir devolve segundos. JavaScript é a famosa exceção, Date.now() e new Date().getTime() devolvem milissegundos. System.currentTimeMillis() de Java segue a mesma convenção, e vários sistemas de banco mais novos (por exemplo o tipo Date BSON do MongoDB) também guardam milissegundos.

O resultado é um bug perene entre linguagens: um backend Go escreve 1700000000 (segundos) em um campo JSON; um cliente Node.js passa isso a new Date(1700000000), mas o JavaScript espera milissegundos, então a data resultante é 1970-01-20 em vez do fim de 2023. A correção é new Date(1700000000 * 1000). Inversamente, enviar um timestamp JS em ms a datetime.fromtimestamp() do Python dá o ano ~55895. O Stack Overflow tem dezenas de variantes da pergunta «JavaScript Date showing 1970», e o descompasso é a raiz na grande maioria.

Este conversor aplica uma heurística: se a entrada for maior que 1.000.000.000.000, trata como milissegundos; caso contrário, como segundos. Funciona porque 1e12 segundos seria o ano 33658 d.C. (muito além de qualquer entrada real em escala de segundos), enquanto 1e12 milissegundos é 9 de setembro de 2001 UTC (dentro da faixa moderna). Timestamps em microssegundos e nanossegundos usados em alguns sistemas científicos e em APIs do kernel Linux elevariam o limite; para esses, é preciso especificar a precisão explicitamente.

O problema do ano 2038 («Y2K38»)

Um inteiro com sinal de 32 bits guarda valores de −2.147.483.648 a +2.147.483.647. Interpretado como segundos desde 1970-01-01 UTC, o momento máximo representável é 03:14:07 UTC de terça-feira, 19 de janeiro de 2038. Um segundo depois, o contador transborda e salta para o valor mais negativo, que decodifica como 20:45:52 UTC de sexta-feira, 13 de dezembro de 1901. Qualquer time_t de 32 bits, qualquer coluna de banco que guarde um inteiro com sinal de 4 bytes para tempo e todo sistema embarcado com firmware anterior a ~2010 está em risco.

A superfície exposta é desconfortável: PLC industriais e controladores SCADA com ciclos de implantação de 15 a 30 anos instalados hoje; colunas TIMESTAMP antigas do MySQL documentadas saturando no limite de 2038; sistemas de arquivos ext3; formatos de protocolo binário (campos RRSIG de DNSSEC, NTPv3, vários barramentos de campo industriais) que empacotam um timestamp de 4 bytes; smart TVs e infotainment automotivo rodando silenciosamente kernels Linux 32 bits antigos. A correção predominante é alargar time_t para 64 bits, o que estende o máximo para cerca de +292 bilhões de anos, além da morte térmica do Sol. Linux 5.6 (março de 2020) adicionou syscalls de tempo 64 bits a todas as arquiteturas 32 bits via o patchset y2038 de Arnd Bergmann; glibc 2.34 (agosto de 2021) tornou time_t 64 bits opt-in via _TIME_BITS=64; Debian 13 «Trixie» (2025) é o primeiro release com o arquivo inteiro recompilado. A Apple deprecou binários 32 bits no macOS 10.15 (2019) e iOS 11 (2017), então o parque consumidor está efetivamente imune.

A superfície de risco restante é esmagadoramente embarcada e dados legados em disco: um kernel 64 bits lendo uma coluna de timestamp 32 bits de um banco legado está tão quebrado quanto o próprio banco. A migração é um problema de formato de dados por aplicação, não apenas um problema de kernel.

JavaScript Date, a API mais amaldiçoada do campo

O objeto Date do JavaScript foi copiado por inteiro do Java 1.0 em maio de 1995 durante o sprint de 10 dias em que Brendan Eich escreveu o LiveScript original. O próprio Java deprecou a maior parte dos métodos de java.util.Date no JDK 1.1 (1997), mas o JavaScript os herdou e não pôde quebrar a compatibilidade web, então eles ficaram. Resultado: uma API em que:

Os meses são indexados a partir de 0 (new Date(2024, 0, 15) = 15 de janeiro), mas os dias são indexados a partir de 1.
getYear() devolve «ano menos 1900», getYear() para 2024 dá 124. getFullYear() foi adicionado depois para devolver 2024 direto.
Date.parse('2024-03-15') é interpretado como meia-noite UTC; Date.parse('2024/03/15') é meia-noite local; Date.parse('March 15, 2024') fica definido pela implementação.
Antes do ECMAScript 5 (dezembro de 2009) o parsing era quase inteiramente definido pela implementação, a mesma string podia produzir valores Date diferentes entre IE, Firefox, Chrome e Safari.

A API Temporal (TC39 Stage 3 desde março de 2021) é a substituta moderna, fornecendo Temporal.Instant, Temporal.PlainDate, Temporal.PlainTime, Temporal.ZonedDateTime e um tipo Temporal.Duration de verdade. O suporte dos navegadores está sendo lançado (Firefox Nightly, Safari 18 parcial, Chrome atrás de uma flag em 2024); os polyfills funcionam, mas adicionam ~25 KB. Moment.js foi colocado em modo de manutenção por seus mantenedores em setembro de 2020, para projetos novos em 2026 a recomendação é Temporal primeiro se o suporte de navegador permitir, Luxon ou date-fns caso contrário, e Moment.js nunca.

Quando você precisa disso

Depuração de respostas de API. A maioria das APIs JSON devolve timestamps ou como inteiros Unix ou como strings ISO 8601, e muitas misturam. Colar um número em um conversor dezenas de vezes por dia é o caso de uso de maior volume.
Análise de logs. syslog, journald, AWS CloudWatch e a maioria dos logs de aplicação têm carimbo em segundos Unix. Engenheiros copiam um timestamp de uma linha de log e precisam do equivalente em relógio de parede.
Inspeção de colunas de data em banco. Uma consulta avulsa psql ou mysql devolve 1700000000; o banco tem funções como FROM_UNIXTIME(), mas uma ferramenta de navegador é mais rápida para trabalho ad hoc.
Inspeção de JWT. Decodificar um token OAuth mostra "exp": 1738367200. O token expirou? Quando expira? Um conversor de timestamp é a resposta mais rápida.
Timestamps de blockchain. O nTime de bloco do Bitcoin é em segundos Unix (transborda em 2106, 4 bytes sem sinal). Os timestamps de bloco do Ethereum também em segundos Unix.
Metadados de sistema de arquivos do SO. ls -l --time-style=+%s imprime mtimes Unix; stat -c '%Y' filename devolve mtime como inteiro. Reconciliação forense de timestamps frequentemente envolve decodificação manual.
Certificado notBefore / notAfter e cabeçalhos HTTP If-Modified-Since, todos são timestamps que ocasionalmente precisam ser decodificados.

Uma nota sobre segundos bissextos

Desde 1972, 27 segundos bissextos foram inseridos no UTC para manter o relógio de parede alinhado com a rotação cada vez mais lenta da Terra. O mais recente foi em 31 de dezembro de 2016 23:59:60 UTC. O tempo Unix não codifica segundos bissextos, o POSIX diz explicitamente que um timestamp Unix finge que todo dia tem exatamente 86.400 segundos. Sistemas Linux antigos «repetem» o último segundo; Google e AWS usam um «leap smear» que espalha o segundo extra por uma janela de 24 horas. De um jeito ou de outro, o tempo Unix nunca lê 23:59:60 em armazenamento, e subtrair dois timestamps que atravessam um segundo bissexto produz uma resposta um segundo menor do que o tempo SI realmente decorrido. Para código de aplicação, é invisível. Para software astronômico ou de trading financeiro, pode importar. Em novembro de 2022, a 27ª Conferência Geral de Pesos e Medidas votou para parar de inserir segundos bissextos até 2035, substituindo-os por um ajuste periódico muito maior.

Referência rápida

Timestamp	UTC datetime	Note
0	1970-01-01 00:00:00	The epoch
1,000,000,000	2001-09-09 01:46:40	First "billion-second" milestone
1,234,567,890	2009-02-13 23:31:30	"Cool number" celebrated by some devs
1,700,000,000	2023-11-14 22:13:20
2,000,000,000	2033-05-18 03:33:20	"Two billionth second"
2,147,483,647	2038-01-19 03:14:07	Last second representable in signed 32-bit
4,294,967,295	2106-02-07 06:28:15	Last representable in unsigned 32-bit (Bitcoin's `nTime` limit)
9,999,999,999	2286-11-20 17:46:39	Last 10-digit timestamp

Mais perguntas

Por que o mesmo timestamp mostra um horário diferente na máquina do meu amigo?

Porque o número subjacente está em UTC, mas a exibição converte para o horário local. 1700000000 é 22:13:20 UTC, mas 17:13:20 em Nova York e 06:13:20 do dia seguinte em Sydney. O número é o mesmo; só a renderização difere. Para descartar confusão de fuso, peça às duas máquinas para exibir em UTC.

Qual é a diferença entre Y2K e Y2K38?

Y2K (ano 2000) foi um problema de lógica no código de aplicação: muitos sistemas guardavam os anos com dois dígitos ASCII, então «00» ficava ambíguo entre 1900 e 2000. Cada aplicação tinha que ser inspecionada e corrigida individualmente; o custo global de remediação foi estimado em 300-600 bilhões de dólares. Y2K38 é sobretudo um problema de tipo de dado em bibliotecas de baixo nível, recompilar a lib C e o kernel contra um time_t 64 bits resolve grande parte da superfície para toda aplicação que linka contra elas. Os casos difíceis restantes são dados persistidos em disco (bancos, metadados de arquivos, protocolos binários) que precisam de ferramentas de migração de dados. A sabedoria convencional é que 2038 será um evento menor e menos noticioso que 2000, mais falhas localizadas em aparelhos embarcados, menos manchetes.

Por que new Date('2024-03-15') às vezes mostra 14 de março?

Porque essa string é interpretada como meia-noite UTC pelo padrão ES5 e depois exibida no seu fuso local. Em uma zona UTC-8 como US Pacific, meia-noite UTC do dia 15 de março é 16h do dia 14 no horário local, então .getDate() devolve 14. A correção em código moderno é ou new Date('2024-03-15T12:00:00') (que o JavaScript interpreta como meio-dia local quando você omite o Z) ou, melhor, a API Temporal.PlainDate.from() quando estiver disponível.

Alguma coisa é enviada para um servidor?

Não. A conversão é aritmética JavaScript rodando localmente no seu navegador. Nada sobre os timestamps que você digita sai da página, útil quando os valores são IDs de cliente, linhas internas de log ou dados de depuração de sessão que você prefere não subir a lugar nenhum. A página funciona offline depois de carregada.