Conversor de timestamp Unix Epoch gratuito

O que é realmente o tempo Unix epoch

O tempo Unix epoch (também chamado tempo POSIX, tempo Unix, ou simplesmente «epoch») é um sistema para representar instantes no tempo como um único inteiro: o número de segundos (ou milissegundos, em JavaScript e muitos sistemas modernos) decorridos desde a epoch Unix, fixada em 00:00:00 UTC de 1 de Janeiro de 1970. Os números negativos representam instantes anteriores à epoch; os positivos, posteriores. A representação por um único inteiro tem propriedades atractivas: é independente do fuso horário (o número é o mesmo em qualquer ponto da Terra no mesmo instante), é fácil de comparar (instantes posteriores são números maiores) e o cálculo de durações é trivial (subtracção). O tempo Unix é a representação subjacente do tempo em praticamente todo sistema operativo, todo motor de base de dados, todo protocolo de API e toda biblioteca padrão de linguagem de programação, mesmo sistemas cujas interfaces de utilizador mostram datas de calendário guardam os valores subjacentes como inteiros epoch.

A escolha de 1 de Janeiro de 1970, e outras epochs

A epoch 1970-01-01 remonta aos primórdios do Unix nos Bell Labs. O tipo time_t do Unix era originalmente um inteiro com sinal de 32 bits a contar segundos desde uma referência escolhida; a equipa escolheu o Ano Novo mais recente antes do início do desenvolvimento, ou seja 1 de Janeiro de 1970. A decisão foi prática, não filosófica, o Unix estava em desenvolvimento entre 1969 e 1971, e uma epoch recente maximizava o intervalo utilizável dos timestamps dentro do intervalo com sinal de 32 bits. Outros sistemas escolheram outras epochs adequadas aos seus casos de uso. NTP (Network Time Protocol, RFC 5905) usa 1 de Janeiro de 1900, importante porque o NTP precisava de cobrir intervalos históricos mais longos. Windows FILETIME usa 1 de Janeiro de 1601 como epoch em ticks de 100 nanossegundos (o início do ciclo gregoriano de 400 anos que incluiu 1601). VAX/VMS usou 17 de Novembro de 1858 (a epoch do dia juliano modificado, popular em astronomia). Mac classic usou 1 de Janeiro de 1904. JavaScript Date usa a epoch Unix mas conta milissegundos em vez de segundos (um flutuante de 64 bits, dando ±100 milhões de anos de intervalo utilizável). Conclusão: a epoch Unix domina em 2026, mas o registo histórico contém muitas outras escolhas, cada uma com a sua própria carga de retrocompatibilidade.

O problema Y2K38, o tempo Unix vai esgotar (mais ou menos)

Se time_t for um inteiro com sinal de 32 bits (o design Unix original), o timestamp máximo representável é 2 147 483 647, o que corresponde a Terça-feira, 19 de Janeiro de 2038, 03:14:07 UTC. Um segundo depois, o valor transborda para o negativo e enrola-se até 13 de Dezembro de 1901. Este é o problema Y2K38 (também chamado Epochalypse). Em sistemas modernos de 64 bits, time_t é um inteiro com sinal de 64 bits e a data de transbordo é 4 de Dezembro de 292 277 026 596, confortavelmente para lá da morte do Sol. Mas os sistemas embebidos de 32 bits continuam em implantação activa em controladores industriais, satélites de longa missão, back-ends bancários, redes SCADA do petróleo e gás, infotainment automóvel e sensores IoT com vidas úteis de várias décadas. A mitigação está em curso desde o início da década de 2000, todo grande sistema operativo, base de dados e linguagem usa agora por defeito tempo de 64 bits em hardware de 64 bits (o Linux concluiu a transição no kernel 5.6, em Março de 2020; o Windows sempre usou 64 bits; o macOS Catalina abandonou o suporte de 32 bits em 2019). Os sistemas embebidos são a cauda longa. O problema Y2K38 não será uma crise de um único dia como foi o Y2K; será uma série de pequenas falhas em sistemas de cauda longa ao longo dos anos a aproximar-se de 2038, exactamente como o Y2K se manifestou sobretudo em sistemas obscuros que ninguém tinha actualizado.

ISO 8601, o outro formato padrão de tempo

Onde o tempo Unix é o formato de transporte, ISO 8601 é o formato legível. Publicado originalmente como ISO 8601:1988, revisto em 2000, 2004 e mais recentemente em ISO 8601-1:2019 e ISO 8601-2:2019, a norma define representações como 2026-05-03T14:30:00Z (em que o Z significa UTC) ou 2026-05-03T14:30:00+01:00 (com o desvio explícito). O «T» separa a data da hora; o desvio final desambigua o fuso horário. Para os protocolos de internet, RFC 3339 (Klyne e Newman, 2002) define um subconjunto estrito do ISO 8601 mais fácil de fazer parsing, é o formato que se vê em respostas JSON de API, timestamps de logs, campos exp/iat de JWT e fluxos OAuth. A relação com o tempo Unix: ISO 8601 é a forma legível de um instante; o tempo Unix é a forma inteira do mesmo instante. Um conversor como este passa de um para o outro em qualquer direcção. A forma hora local (2026-05-03T14:30:00 sem desvio) é ambígua e deve ser evitada em qualquer sistema que cruze fusos horários, é frequentemente a fonte de bugs subtis em que uma API JSON afirma devolver timestamps mas não diz em que fuso estão.

Segundos vs milissegundos, a confusão mais comum

Ao nível do sistema operativo, o tempo Unix conta segundos: um inteiro de 10 dígitos para qualquer instante entre cerca de 2001 e 2286 (timestamps anteriores a 2001 tinham 9 dígitos ou menos). O Date.now() do JavaScript, o System.currentTimeMillis() da JVM, o DateTimeOffset.ToUnixTimeMilliseconds() do .NET e a maioria das APIs web contam milissegundos: um inteiro de 13 dígitos para o mesmo intervalo. As duas formas diferem exactamente por um factor de 1000, e o bug mais comum relacionado com timestamps em qualquer código que comunique com vários sistemas consiste em fornecer um valor em milissegundos a uma função que espera segundos (dando uma data 1000× mais longe no futuro do que pretendido) ou vice-versa (dando uma data a uma fracção de segundo após a epoch). Este conversor detecta automaticamente segundo o número de dígitos: 10 dígitos ou menos = segundos, 13 ou mais = milissegundos. Para valores intermédios (11–12 dígitos, ambíguos), o conversor prefere a interpretação que dá uma data sensata. Os microssegundos (16 dígitos, usados por alguns sistemas de alta precisão e muitos tipos TIMESTAMP de bases de dados) e os nanossegundos (19 dígitos, usados pelo Linux clock_gettime, pelo Go time.UnixNano(), pelo tooling de observabilidade moderno como o OpenTelemetry) também aparecem mas são menos comuns em dados voltados ao utilizador.

Onde realmente precisa desta conversão

• Leitura de respostas de API. Um endpoint REST devolve "created_at": 1714665600: que data é? Cole, leia «2 de Maio de 2024 16:00:00 UTC», siga com a sessão de depuração. Stripe, GitHub, AWS e a maioria das APIs empresariais usam inteiros de tempo Unix para campos de data precisamente para evitar a ambiguidade de fuso horário.
• Decodificação de timestamps de logs. Os logs de servidor frequentemente registam horas como inteiros Unix por compactabilidade e velocidade de parsing. Ler «1714665600.234 ERROR connection refused» exige converter o número inicial numa hora de calendário para correlacionar com outros eventos.
• Depuração de JWT. Os claims exp (expiração) e iat (emitido em) em JSON Web Tokens são inteiros de tempo Unix segundo a RFC 7519. Para verificar se um token expirou ou para ver quando foi emitido, cole o valor aqui.
• Cálculo de diferença temporal. Subtraia dois timestamps Unix para obter a duração entre eles em segundos (ou milissegundos). Sem matemática de fuso horário, sem ajuste DST, sem casos limite de aritmética de calendário.
• Consultas de base de dados com colunas epoch. Muitas bases de dados mais antigas guardam timestamps como inteiros Unix. Consultar «todos os eventos entre X e Y» exige converter as datas-limite legíveis em inteiros Unix para a cláusula WHERE.
• Agendamento e tarefas cron. Sistemas que agendam jobs por hora absoluta (Kubernetes CronJobs, AWS EventBridge, Azure Logic Apps) frequentemente querem alvos em tempo Unix na sua configuração. Converta a hora-alvo amigável em epoch.
• Decodificação de timestamps «interessantes». Valores epoch famosos: 0 = 1 de Janeiro de 1970 00:00:00 UTC (a própria epoch); 1234567890 = 13 de Fevereiro de 2009 23:31:30 UTC (brevemente celebrado como o momento «Unix billion»); 1500000000 = 14 de Julho de 2017 02:40:00 UTC; 2000000000 = 18 de Maio de 2033 03:33:20 UTC; 2147483647 = 19 de Janeiro de 2038 03:14:07 UTC (o ponto de transbordo Y2K38).

Uma nota sobre segundos intercalares e o tempo «real»

Uma complicação subtil: o tempo Unix tal como definido pelo POSIX não inclui segundos intercalares. O tempo universal coordenado (UTC) acrescenta ocasionalmente um segundo intercalar para manter o tempo civil alinhado com a rotação real da Terra, foram acrescentados 27 segundos intercalares desde que o sistema arrancou em 1972. O tempo Unix finge que esses segundos intercalares não aconteceram: quando se insere um segundo intercalar no fim de um dia, o relógio ou repete o último segundo (comportamento tradicional do Linux) ou espalha-o por um período mais longo (a abordagem «leap smear» da Google, adoptada pela AWS e muitos CDNs). Para a maior parte do uso aplicacional, isto não importa, a precisão sub-segundo raramente é significativa ao nível da aplicação. Para trabalho científico de alta precisão, timestamps de sistemas de trading financeiro ou timestamps com valor probatório judicial, o comportamento perante segundos intercalares é uma fonte conhecida de casos limite. O IERS (International Earth Rotation and Reference Systems Service) anuncia os segundos intercalares com seis meses de antecedência; o mais recente foi inserido no fim de 31 de Dezembro de 2016, e a comunidade internacional tem ponderado retirar inteiramente os segundos intercalares (a resolução para o fazer até 2035 foi adoptada na Conferência Geral de Pesos e Medidas de 2022).

Privacidade: conversão apenas no navegador

Os timestamps que cola não costumam ser sensíveis em si mesmos (um inteiro Unix só revela um instante no tempo), mas o contexto, uma linha de log que contém um identificador real de utilizador junto ao timestamp, um JWT contendo claims sobre um utilizador real, uma resposta de API com IDs internos de entidades, é frequentemente sensível. Este conversor corre inteiramente no seu navegador através da API Date incorporada do JavaScript. Sem upload, sem registo, verifique no separador Rede das DevTools enquanto digita um timestamp (não dispara nenhum pedido) ou ponha a página offline (modo de avião) após o carregamento. O ecrã «now» em actualização contínua usa o seu relógio local, não uma fonte de tempo de rede.

Perguntas frequentes

O que é um timestamp Unix ?

Um timestamp Unix (também chamado tempo Epoch ou tempo POSIX) é o número de segundos decorridos desde 1 de Janeiro de 1970 às 00:00:00 UTC, seguindo a abstracção POSIX do Unix (que não conta segundos intercalares) em vez de segundos reais decorridos do relógio atómico. Muitos sistemas modernos usam milissegundos em vez de segundos para precisão sub-segundo (Date.now() do JavaScript, System.currentTimeMillis() do Java, DateTimeOffset.ToUnixTimeMilliseconds() do .NET). O tempo Unix é a representação temporal padrão em praticamente todo sistema operativo, base de dados e API web.

Qual a diferença entre segundos e milissegundos ?

Um factor de 1000. Os timestamps Unix com precisão de segundos em 2026 têm 10 dígitos (p. ex. 1714665600); com precisão de milissegundos têm 13 dígitos (p. ex. 1714665600234). Este conversor detecta automaticamente segundo o número de dígitos. O bug mais comum em código que mistura as duas formas consiste em fornecer milissegundos a uma função que espera segundos (dando uma data 1000× mais longe no futuro do que pretendido) ou vice-versa.

Por que minha hora convertida está com várias horas de diferença ?

O tempo Unix é independente do fuso horário, mas a forma legível depende de em que fuso o exibe. O conversor mostra três formatos em simultâneo: Hora local (o fuso do seu navegador), UTC (Greenwich) e ISO 8601 (com desvio explícito). Se o resultado não corresponde ao que esperava, verifique o fuso, o seu valor «esperado» estava provavelmente num fuso diferente do formato que leu.

Qual é o problema Y2K38?

Se o tempo Unix for guardado num inteiro com sinal de 32 bits (o design Unix original), transborda em 19 de Janeiro de 2038 às 03:14:07 UTC. Os sistemas modernos de 64 bits não são afectados, a data de transbordo desloca-se para aproximadamente o ano 292 mil milhões. O risco Y2K38 concentra-se em sistemas embebidos de 32 bits ainda em implantação (controladores industriais, satélites, infotainment automóvel, back-ends bancários, sensores IoT com vidas úteis de várias décadas). Ao contrário do Y2K, o problema Y2K38 não será uma crise de um único dia mas uma série de pequenas falhas em sistemas de cauda longa ao longo dos anos a aproximar-se de 2038.

Funciona offline?

Sim, uma vez carregada a página, toda a conversão corre no seu navegador através da API Date incorporada do JavaScript. Sem chamadas de rede durante o uso. O botão «Now» usa o relógio local do seu dispositivo; o timestamp em actualização contínua no topo actualiza-se a partir do relógio do sistema sem contactar qualquer servidor de tempo.

Ferramentas relacionadas