Gerador de carimbo de data/hora Unix

Como funciona

1. Converter uma data em timestamp : insira uma data e hora com o seletor, depois clique em Gerar para obter o timestamp Unix em segundos e milissegundos.
2. Converter um timestamp em data : cole um timestamp Unix (segundos ou milissegundos) para reconvertê-lo em data e hora legíveis.
3. Obter o timestamp atual : clique em « Agora » para obter instantaneamente o timestamp Unix do momento presente.

Por que usar o gerador de timestamp Unix ?

Os timestamps Unix são a linguagem universal do tempo na computação, um único inteiro representando os segundos decorridos desde 1º de janeiro de 1970 (UTC). Eles alimentam bancos de dados, APIs, logs, tokens de autenticação e agendamento de eventos. Converter manualmente entre timestamps e datas legíveis envolve cálculos de fuso horário fáceis de errar. Esta ferramenta trata corretamente a conversão nos dois sentidos, economiza tempo e evita bugs de fuso horário.

Funcionalidades

• Conversão bidirecional : data/hora → timestamp Unix e timestamp Unix → data/hora.
• Segundos e milissegundos : suporta o tempo Unix em segundos (10 dígitos) e em milissegundos (13 dígitos).
• Gestão de fusos : exibe a hora no seu fuso local e em UTC para uma comparação sem ambiguidade.
• Botão hora atual : obtenha instantaneamente o timestamp do momento presente.
• Exibição relativa : indica há quanto tempo ou em quanto tempo (por ex. « há 3 dias »).

Perguntas frequentes

O que é um timestamp Unix ?

Um timestamp Unix é o número de segundos decorridos desde a época Unix, meia-noite UTC de 1º de janeiro de 1970. É uma representação de um instante independente de fusos, o que o torna o formato preferido para armazenar e comparar instantes em bancos de dados e APIs.

Por que o JavaScript usa milissegundos ?

Date.now() e new Date().getTime() em JavaScript retornam milissegundos desde a época (um número de 13 dígitos), enquanto as ferramentas Unix e a maioria dos bancos de dados usam segundos (10 dígitos). Verifique se seu timestamp tem 10 ou 13 dígitos para saber qual formato você tem.

Como converter um timestamp em hora local ?

Cole o timestamp ; a ferramenta o converte automaticamente para o fuso local do seu navegador. A exibição mostra ao mesmo tempo a hora local e o UTC para trabalhar entre fusos com confiança.

De onde vem o tempo Unix

O tempo Unix foi definido por Ken Thompson e Dennis Ritchie no Unix First Edition (novembro de 1971). Inicialmente o kernel contava 60avos de segundo desde 1971-01-01 em um campo de 32 bits, que transbordava após 2 anos 9 meses. Em Unix Sixth Edition (1975) a contagem foi alterada para segundos desde 1970-01-01 00:00:00 UTC, a época que todo sistema tipo Unix ainda usa hoje. A escolha foi arbitrária, os engenheiros precisavam de uma data redonda próxima da era em que trabalhavam. POSIX.1 (1988) codificou a definição como o padrão oficial, e POSIX.1-2017 (IEEE Std 1003.1-2017), a versão atual, ainda define time_t como o número de segundos desde a época, com a ressalva de que o tempo POSIX finge que segundos intercalares não existem. ISO 8601 (1988, atualmente 2019) padronizou o formato legível 2026-05-13T14:30:00Z, e RFC 3339 (julho de 2002) o restringiu a um perfil de data-hora de internet inequívoco. Date.now() do JavaScript retorna milissegundos desde a época porque a spec foi escrita em 1995 quando precisão sub-segundo já estava em demanda; a maioria de bancos de dados e utilitários Unix ainda usa segundos inteiros.

O problema do ano 2038 (e por que importa agora)

Um time_t com sinal de 32 bits pode representar no máximo 2.147.483.647 segundos, que chega às 03:14:07 UTC na terça-feira, 19 de janeiro de 2038. Um segundo depois, o contador envolve para −2.147.483.648, que a maioria do software interpreta como 13 de dezembro de 1901. É a mesma classe de bug que Y2K mas causada pela largura de inteiro, não pelo formato de data. A solução é usar time_t de 64 bits (que empurra o transbordamento para aproximadamente o ano 292 bilhões). A maioria dos sistemas Linux de 64 bits já usa time_t de 64 bits por padrão; Linux 5.6 (março de 2020) tornou time_t de 64 bits disponível também em arquiteturas de 32 bits. O risco restante vive em sistemas embarcados, formatos de arquivo binários antigos e protocolos de rede de 32 bits. O protocolo NTP já envolve em 2036 porque usa um contador sem sinal de 32 bits desde 1900, NTPv4 adiciona um número de era para estendê-lo. Se você entrega software que lida com datas, audite seu stack antes de 2038, especialmente colunas SQL tipadas como INT(11) ou código C antigo com campos de tempo long.

Os formatos de timestamp que você encontrará

• Segundos Unix (10 dígitos). 1747143000. O time_t POSIX clássico. Usado por PostgreSQL EXTRACT(epoch FROM ...), MySQL UNIX_TIMESTAMP(), TTLs Redis, claims iat/exp JWT (conforme RFC 7519), git log, e a maioria de utilitários Unix. Terá 11 dígitos após novembro de 2286.
• Milissegundos Unix (13 dígitos). 1747143000000. Date.now() do JavaScript, System.currentTimeMillis() do Java, Kafka, Elasticsearch, e a maioria de pipelines de logs modernos. Multiplicado por 1000 a contagem de segundos.
• Microssegundos Unix (16 dígitos) e nanossegundos (19 dígitos). 1747143000000000. Usado por time.time_ns() do Python, time.Now().UnixNano() do Go, revisões MVCC etcd e sistemas de trading de alta frequência onde a resolução de milissegundos é grosseira demais.
• ISO 8601. 2026-05-13T14:30:00.000Z ou 2026-05-13T14:30:00+02:00. Ordenável como string, inequívoco sobre fuso horário, aceito por praticamente toda API moderna. O sufixo Z significa «horário Zulu», um designador OTAN para UTC.
• RFC 3339. Um perfil mais estrito de ISO 8601 usado por JSON Schema, OpenAPI, e a maioria de APIs REST. Requer um designador de fuso horário e proíbe algumas características ISO 8601 como datas de semana e datas ordinais.
• RFC 2822 / RFC 5322. Tue, 13 May 2026 14:30:00 +0000. O formato do cabeçalho de e-mail Date:. Ainda onipresente porque SMTP roda em todo lugar.
• Data serial do Excel. Dias fracionários desde 1900-01-01 (ou 1904 no Excel Mac clássico). 2026-05-13 14:30 é aproximadamente 46150.6042. Excel trata famosamente 1900 como ano bissexto (não é) por compatibilidade com Lotus 1-2-3.

Quando esta ferramenta ganha seu sustento

• Depuração de JWT. O token tem "exp": 1747143000 e você precisa saber se expirou. Cole, veja a data humana.
• Forense de logs. Uma linha diz timestamp=1747143012345, você precisa correlacionar com o tempo de relógio de parede de outra ferramenta. 13 dígitos, então milissegundos.
• Consultas de banco de dados. Você quer encontrar linhas após uma data específica. WHERE created_at > 1747143000 precisa do valor em segundos; copie da ferramenta.
• Fixtures de testes. Codificar «ontem» em um teste, você gera o timestamp agora e cola no spec.
• Cron / jobs agendados. Verifique o valor em segundos que um agendador disparará, especialmente através de transições DST.
• Replay de eventos. Offsets Kafka e índices Elasticsearch frequentemente usam timestamps ms; converta em data para inspecionar uma janela de replay específica.
• Invalidação de cache. Um cabeçalho Expires ou If-Modified-Since em formato RFC 2822, gere o formato wire correto para testes.

Erros que custam horas às equipes

• Misturar segundos e milissegundos. Passar um valor de 10 dígitos a uma função esperando milissegundos retorna uma data em 1970, desviada por um fator de 1000. A regra 10-vs-13 dígitos é o teste mais rápido, valores modernos em segundos têm 10 dígitos até 2286, em milissegundos 13 dígitos.
• Armazenar hora local. Sempre armazene UTC; converta para local no tempo de exibição. Armazenar "2026-05-13 14:30:00" sem fuso horário quebra no momento em que um servidor, usuário ou salto DST muda o offset local.
• Esquecer as transições DST. 2:30 da manhã acontece duas vezes durante o recuo. Código ingênuo que faz start + (24 * 3600) para significar «amanhã» estará desviado por uma hora duas vezes por ano. Use uma biblioteca de datas real (luxon, date-fns-tz, zoneinfo do Python) que conhece o banco de dados IANA tz.
• Assumir que o tempo POSIX conta os segundos intercalares. Não conta. 2016-12-31 23:59:60 existiu na vida real (o 27º segundo intercalar) mas o time_t POSIX salta de 23:59:59 para 00:00:00 sem consciência do segundo extra. TAI (Tempo Atômico Internacional) conta os segundos intercalares, o tempo POSIX é deslocado de UTC por zero segundos.
• Armazenar time_t em colunas INT(4). Esquemas MySQL antigos frequentemente usam INT que é 4 bytes / 32 bits com sinal / envolve em 2038. Migre para BIGINT ou TIMESTAMP. O tipo TIMESTAMP de provedores MySQL hospedados também é 4 bytes por padrão, verifique a doc.
• Parsear ISO 8601 com regex. Implementações pela metade descartam silenciosamente o fuso horário. Use o parser da plataforma: new Date(s) em JavaScript, datetime.fromisoformat(s) em Python ≥ 3.11, Instant.parse(s) em Java.
• Excel auto-converte timestamps. Colar 1747143012345 no Excel sem prefixá-lo com ' (um apóstrofo literal) faz com que Excel o leia como número, às vezes convertendo para notação científica. Ou formate a coluna como Texto primeiro, ou cole com o prefixo apóstrofo.

Mais perguntas frequentes

Por que 1970-01-01 foi escolhido como época?

Conveniência. Versões iniciais do Unix nos anos 70 queriam uma época que não transbordasse dentro de uma vida útil de trabalho razoável. 1970-01-01 era uma data redonda próxima da era de desenvolvimento, e um contador de segundos de 32 bits a partir dali alcança confortavelmente 2038. A escolha está agora gravada em POSIX.1-2017 §4.16 e é um dos acordos multiplataforma mais estáveis em software. Não há significado inerente à data, nenhum evento histórico, nenhuma âncora astronômica, apenas uma âncora arbitrária com a qual todos concordaram.

Qual é a diferença entre UTC, GMT e horário Zulu?

Para propósitos de software, eles se referem ao mesmo tempo de relógio de parede. UTC (Tempo Universal Coordenado) é o padrão moderno, definido por relógios atômicos e o BIPM. GMT (Greenwich Mean Time) é o antigo padrão astronômico britânico que era a referência mundial de facto antes do cronometragem atômica. Horário Zulu é o designador OTAN/militar para UTC, escrito como o sufixo Z em ISO 8601 (2026-05-13T14:30:00Z). UTC e GMT podem diferir até 0,9 segundo porque UTC é dirigido a permanecer próximo a UT1 (tempo solar médio) via segundos intercalares, mas nenhuma aplicação que não use UT1 diretamente notará.

Por que às vezes 1970 é mostrado quando eu esperava outra coisa?

Duas causas comuns. Primeiro, o timestamp está em milissegundos mas foi passado a uma função esperando segundos, ou vice-versa, dando uma data desviada por um fator de 1000. Segundo, o valor é 0 ou NaN, ambos os quais a maioria de bibliotecas de datas renderizam como 1970-01-01T00:00:00Z. Inspecione a largura inteira bruta: 10 dígitos é segundos, 13 é milissegundos, 16 é microssegundos, 19 é nanossegundos.

Esta ferramenta vai lidar com timestamps negativos para datas antes de 1970?

Sim. new Date(-86400000) retorna 1969-12-31T00:00:00Z. A Date do JavaScript pode representar qualquer momento de −271821-04-20 até +275760-09-13, que é aproximadamente ±100 milhões de dias desde a época. Além desse intervalo, a API retorna Invalid Date. Para datas históricas, esteja ciente também da transição juliana-gregoriana (1582 em países católicos, 1752 na Grã-Bretanha, até 1923 na Grécia) onde datas do calendário saltaram de 10 a 13 dias; bibliotecas de datas variam em como lidam com isso.

Meus dados de timestamp são enviados a algum lugar?

Não. Toda conversão executa em JavaScript dentro do seu navegador. A página nunca POSTa qualquer valor que você insere. Abra a aba Rede no DevTools e converta um timestamp, você verá zero requisições de saída durante a conversão. Seguro para tokens com claims de timestamp, linhas de log internas, ou qualquer coisa que você não colaria em um serviço hospedado.