Conversor de Timestamp Unix

Timestamps Unix sem dor de cabeça

Pergunte a três desenvolvedores que horas são e você pode receber três respostas, dependendo de onde cada um está. Pergunte a um timestamp Unix e você recebe exatamente um número, o mesmo para todo mundo no planeta. Esse único inteiro é a razão de o tempo epoch sustentar discretamente quase todo arquivo de log, linha de banco de dados e resposta de API que você um dia vai tocar. Esta página explica o que esse número significa, como lê-lo nos dois sentidos e onde ele costuma pegar as pessoas.

O que é, de fato, o tempo Unix

Um timestamp Unix é o número de segundos decorridos desde 00:00:00 UTC de 1º de janeiro de 1970, sem contar os segundos bissextos. Esse instante é chamado de epoch, e foi escolhido pelos primeiros engenheiros do Unix simplesmente por ser uma data redonda e conveniente a partir da qual contar. No epoch, o valor é exatamente 0. Cada segundo desde então adiciona um, então o número só cresce. Datas anteriores a 1970 também são perfeitamente válidas, expressas como inteiros negativos.

Você também verá esse conceito chamado de tempo POSIX ou, de forma frouxa, tempo epoch. Seja qual for o rótulo, a mecânica é a mesma: um único contador de segundos sempre crescente. Por ser um inteiro simples, e não uma string formatada, um computador consegue armazená-lo em poucos bytes e comparar dois deles com uma única subtração.

Segundos, milissegundos e companhia

O tempo Unix clássico conta segundos inteiros, o que dá o conhecido número de dez dígitos que você vê hoje. Mas muitos ambientes precisam de resolução mais fina. O JavaScript, por exemplo, trabalha em milissegundos, produzindo um valor de treze dígitos, e alguns sistemas vão além, para microssegundos ou nanossegundos. Uma regra prática confiável: um número de dez dígitos é segundos, treze dígitos é milissegundos. Se a sua data convertida cair em algum ponto perto de 1970 quando você esperava os dias atuais, é quase certo que você alimentou milissegundos em um campo de segundos, ou o inverso. Nosso conversor detecta a magnitude automaticamente, então você raramente precisa adivinhar.

Por que os desenvolvedores se apoiam nele

A grande vantagem é que um timestamp é neutro em fuso horário. O inteiro 1735689600 se refere ao mesmo instante em Tóquio, Berlim e São Paulo. Armazenar esse número em vez de uma string local formatada significa que você nunca precisa se perguntar a qual relógio um valor pertencia. A ordenação também é trivial, porque ordem cronológica é apenas ordem numérica, então um índice de banco de dados sobre uma coluna de timestamp ordena os eventos corretamente sem nenhuma análise. A aritmética é igualmente limpa: o intervalo entre dois eventos é uma subtração, e somar um dia é somar 86400. São exatamente essas propriedades que levam logs, tokens, caches e filas de mensagens a recorrerem ao tempo epoch.

Convertendo nos dois sentidos

Ir de um timestamp para uma data legível significa pegar a contagem de segundos e projetá-la sobre um calendário, então formatá-la no fuso horário que importa para você. No caminho inverso, você pega um ano, mês, dia e hora, decide em qual fuso horário isso está expresso e colapsa de volta em segundos desde o epoch. Nossa ferramenta faz as duas direções instantaneamente e inteiramente no seu navegador, então nada do que você cola sai da sua máquina. Cole um número para decodificá-lo, ou escolha uma data para codificá-la, e leia o resultado em UTC e no seu horário local ao mesmo tempo.

UTC versus horário local, a armadilha clássica

O timestamp em si não tem fuso horário; está sempre ancorado ao UTC. A confusão aparece apenas quando você o exibe. Se você converte 1700000000 e a sua tela mostra uma hora da noite enquanto um colega em outro país vê uma hora da tarde, nada está quebrado: vocês dois estão olhando para o mesmo instante renderizado em relógios locais diferentes. Os bugs se infiltram quando o código lê uma data local como se fosse UTC, ou registra uma hora de relógio de parede sem anotar o deslocamento. O hábito seguro é armazenar e transmitir em UTC, e só aplicar um deslocamento local no último momento, quando você mostra o valor a uma pessoa. Na dúvida, compare com a linha de UTC no conversor, e não com a local.

O problema do ano 2038

Muitos sistemas antigos armazenavam o tempo Unix em um inteiro de 32 bits com sinal. Esse campo fica sem espaço um segundo após 03:14:07 UTC de 19 de janeiro de 2038, quando o contador transborda e dá a volta para um número negativo, podendo jogar as datas de volta para 1901. É a mesma família de problema do bug do milênio. A boa notícia é que sistemas operacionais e linguagens modernas migraram em grande parte para timestamps de 64 bits, que não vão transbordar por cerca de 292 bilhões de anos, então, para código novo, isso é mais uma curiosidade histórica que vale conhecer do que uma emergência.

Para mais ajudantes baseados no navegador, veja nossas ferramentas para desenvolvedores, e, se você precisa trabalhar os próprios números, as calculadoras estão a um clique de distância.

Perguntas frequentes