FlowingDev

Tempo Epoch, Explicado: O Relógio que Só Anda pra Frente

Aprenda o que é o tempo Unix (ou Epoch time): o número de segundos que se passaram desde 1º de janeiro de 1970, que os computadores usam pra registrar o tempo de forma universal.

Testar a ferramenta: Conversor de Época

Em uma frase

Epoch time é o jeito do computador registrar o tempo como um número único e sempre crescente: o total de segundos que se passaram desde a meia-noite UTC de 1º de janeiro de 1970.

O problema que ele resolve

Humanos e o tempo têm uma relação complicada. Temos fusos horários, horário de verão e formatos como MM/DD/YYYY vs. DD/MM/YYYY. Escrevemos "8 de outubro de 2024 às 15:00", mas isso significa algo diferente em Tóquio do que em Toronto. É uma bagunça cheia de ambiguidades.

Computadores, por outro lado, detestam ambiguidade. Eles precisam de uma forma única, universal e matematicamente simples de representar um momento no tempo. Tentar fazer contas com "8 de outubro" é um pesadelo. Mas fazer contas com um simples número? É pra isso que os computadores foram feitos.

Este é o problema que o tempo Unix (também chamado de Epoch time ou tempo POSIX) foi criado para resolver. Lá no início do sistema operacional Unix, nos anos 70, seus criadores precisavam de um sistema simples para registrar o tempo. Eles decidiram escolher um ponto de partida arbitrário — uma "epoch" — e simplesmente... contar.

A epoch escolhida foi 00:00:00 UTC, 1º de janeiro de 1970. Por que essa data? Era um número bonito e redondo, e era recente o suficiente para a tecnologia da época.

A partir daquele momento, cada segundo que passa incrementa um contador universal. Então, em vez de um computador ter que interpretar "15:00 de 8 de outubro de 2024, em Toronto (que é EDT)", ele pode simplesmente armazenar o número 1728409200. Esse número representa aquele momento exato no tempo, em todos os lugares da Terra, simultaneamente. Sem fusos horários, sem formatos, sem "é AM ou PM?". Apenas um número. Problema resolvido.

Como funciona por debaixo dos panos

Na sua essência, o conceito é ridiculamente simples. Mas, como tudo em tecnologia, o diabo mora nos detalhes.

A Epoch e a Unidade

O sistema todo é construído sobre duas ideias:

  1. O Ponto de Partida (Epoch): É fixo em 1970-01-01T00:00:00Z. O Z significa Zulu, um termo militar e da aviação para UTC (Tempo Universal Coordenado). No mundo do Epoch time, este momento é simplesmente 0.
  2. A Unidade de Medida: A unidade padrão e oficial é o segundo.

Então, o timestamp 1 representa 1970-01-01T00:00:01Z. O timestamp para o início do dia seguinte, 1970-01-02T00:00:00Z, é 86400 (porque há 60 segundos * 60 minutos * 24 horas = 86.400 segundos em um dia).

// A date far in the future
const humanDate = new Date('2035-10-26T10:00:00Z');

// Its corresponding Epoch timestamp in seconds
const epochTimestamp = 2071754400;

Quando seu computador te mostra esse timestamp como uma hora local, ele está fazendo uma conversão por trás dos panos. Ele pega o timestamp universal UTC e aplica o deslocamento de fuso horário do seu sistema para exibi-lo de uma forma que faça sentido para você. O número por baixo, no entanto, permanece puro e universal.

Variações: Milissegundos, Microssegundos, Nanossegundos

Às vezes, você precisa medir coisas que acontecem mais rápido que um segundo. Para isso, os sistemas usam versões mais precisas do Epoch timestamp. O princípio é o mesmo, mas a unidade muda.

Unidade Valor de Exemplo (para o mesmo momento) Contagem de Dígitos Comum Caso de Uso Típico
Segundos 1728409200 10 O padrão POSIX; APIs, bancos de dados.
Milissegundos 1728409200123 13 JavaScript (Date.now()), APIs modernas.
Microssegundos 1728409200123456 16 Sistemas de alta performance, alguns bancos de dados.
Nanossegundos 1728409200123456789 19 Computação científica, linguagem Go.

Esta é a principal fonte de bugs ao trabalhar com timestamps. Se um sistema te dá um número de 13 dígitos e você o trata como segundos, você está tentando calcular uma data a milhares de anos no futuro. Sempre verifique a documentação ou olhe o número de dígitos para saber com o que está lidando.

O "Problema do Ano 2038"

Aqui vai uma pérola clássica da sabedoria popular da computação. Muitos sistemas antigos, para economizar a preciosa memória, armazenavam o Epoch timestamp como um inteiro de 32 bits com sinal (signed integer).

Um "bit" é um 1 ou um 0. "32-bit" significa que você tem 32 espaços para 1s e 0s. "Signed" (com sinal) significa que um desses bits é usado para indicar se o número é positivo ou negativo. Isso deixa 31 bits para o número em si, que pode representar um valor máximo de 2^31 - 1, ou 2.147.483.647.

O que acontece quando o número de segundos desde 1970 atingir esse limite? Isso acontecerá na terça-feira, 19 de janeiro de 2038, às 03:14:07 UTC. No segundo seguinte, o inteiro sofrerá um overflow. Como o hodômetro de um carro virando de 999999 para 000000, o timestamp de 32 bits dará a volta para seu valor mais negativo (-2.147.483.648). Isso corresponde a uma data em dezembro de 1901.

Para qualquer sistema de 32 bits que não tenha recebido um patch, isso causará um caos cronológico. Pense em sistemas embarcados em carros mais antigos, equipamentos industriais ou roteadores de rede.

A solução? Usar um inteiro de 64 bits. Um inteiro de 64 bits pode armazenar um número tão absurdamente grande que não sofrerá overflow por cerca de 292 bilhões de anos. Até lá, o sol já terá se expandido e engolido a Terra, então provavelmente podemos chamar isso de uma solução permanente. A maioria dos sistemas operacionais e linguagens modernos já fez essa transição.

Segundos Bissextos: A Mosca na Sopa

A rotação da Terra não é perfeitamente regular; ela está desacelerando ligeiramente. Para manter nossos relógios atômicos (que são super regulares) em sincronia com o dia solar, órgãos internacionais ocasionalmente adicionam um "segundo bissexto" (leap second) ao calendário. Isso significa que um minuto pode ter 61 segundos (ex: 23:59:60).

Então, como o Epoch time lida com isso? Ele não lida.

Oficialmente, o padrão POSIX ignora os segundos bissextos. Ele assume que todo dia tem exatamente 86.400 segundos. Quando um segundo bissexto ocorre, os sistemas lidam com isso de algumas maneiras, mas uma comum é efetivamente repetir o segundo anterior. O timestamp para 23:59:59 pode ocorrer duas vezes. Isso mantém a contagem contínua e ininterrupta de segundos, mas significa que um timestamp Unix nem sempre corresponde perfeitamente ao UTC do mundo real. Para 99,9% das aplicações, isso não é um problema. Para negociações de alta frequência (high-frequency trading) ou medições científicas, é uma dor de cabeça gigantesca.

Histórias do Mundo Real

O Caso do Cache Viajante no Tempo

Uma equipe de desenvolvimento estava lançando uma nova funcionalidade que usava um sistema de cache. Para melhorar a performance, eles armazenavam os dados em cache por uma hora. A lógica era simples: tempo_de_expiracao = tempo_atual() + 3600. Eles fizeram o deploy do código em toda a sua frota de servidores.

De repente, bugs estranhos começaram a aparecer. Os dados estavam desaparecendo do cache quase que instantaneamente. Após horas de debugging frenético, eles encontraram o culpado. Um dos novos servidores na frota estava com o relógio do sistema configurado incorretamente — ele estava rodando cinco minutos atrasado em relação a todos os outros servidores.

Quando a requisição de um usuário chegava a um servidor correto, ele cacheava o dado com um tempo de expiração de, digamos, 1678886400 (12:00). Se uma requisição subsequente para o mesmo dado chegasse ao servidor "lento", cujo relógio marcava 11:55, ele checava o cache, via um tempo de expiração de 12:00 e servia o dado corretamente. Mas se a primeira requisição chegasse ao servidor lento, ele definiria um tempo de expiração de 1678882800 (11:00, sua própria hora, mais uma hora que dá 12:00). Mas já eram 11:55. Espera, isso não está certo.

Vamos tentar de novo. A hora do Servidor A é 12:00. Ele define uma expiração de cache para 12:00 + 1 hora = 13:00. O relógio do Servidor B está atrasado; ele acha que são 11:55. Quando o Servidor B precisa escrever no cache, ele define uma expiração de 11:55 + 1 hora = 12:55. Agora, se o Servidor A vê um item que expira às 12:55, ele pensará que ainda faltam 55 minutos, enquanto o Servidor B acha que tem uma hora inteira. Isso leva a inconsistências.

O verdadeiro caos começa quando os relógios estão muito dessincronizados. Se o relógio do Servidor B estivesse uma hora atrasado (achando que são 11:00 quando na verdade são 12:00), ele definiria um tempo de expiração de 11:00 + 1 hora = 12:00. Da perspectiva do Servidor A, este novo item de cache expira no mesmo segundo em que foi criado. O dado efetivamente sumia.

Lição: Timestamps Unix são absolutos, mas são gerados a partir de relógios de sistema que podem não ser. Em sistemas distribuídos, manter os relógios sincronizados (geralmente com o Protocolo de Tempo de Rede, ou NTP) não é apenas uma boa prática; é crucial.

A API que Falava em Milissegundos

Um desenvolvedor frontend estava construindo um dashboard para exibir a atividade do usuário. A API do backend fornecia um campo last_login com um timestamp, como 1678886400. O desenvolvedor usou uma biblioteca JavaScript para mostrar isso: new Date(1678886400).

O resultado foi bizarro. O último login de todos os usuários era exibido como "20 de janeiro de 1970". O que estava acontecendo?

O desenvolvedor passou uma hora culpando a biblioteca, seu código e a fase da lua. Finalmente, ele tentou integrar um endpoint diferente da mesma API. Desta vez, o timestamp era 1678886400123. Tinha 13 dígitos! De repente, a ficha caiu. O construtor do objeto Date do JavaScript espera um timestamp em milissegundos, não em segundos.

O backend estava enviando um timestamp padrão de 10 dígitos baseado em segundos. O frontend estava interpretando 1.678.886.400 como o número de milissegundos desde a epoch, o que resulta numa data poucas semanas após o início da epoch em 1970. A correção foi simples: new Date(1678886400 * 1000).

Lição: Sempre, sempre, sempre verifique a precisão de um timestamp. Uma diferença de três zeros é a diferença entre hoje e 1970.

Erros e Armadilhas Comuns

  • Esquecer o fuso horário. Timestamps Unix são sempre, sem exceção, em UTC. Quando você converte um para uma data legível por humanos, sua linguagem de programação ou ferramenta quase sempre usará o fuso horário local do seu computador. Isso pode causar uma confusão enorme se você não levar isso em conta. 1728409200 é um momento exato no tempo, mas será exibido como 06:00 em Nova York e 19:00 em Tóquio. O número é a verdade; a exibição é uma interpretação.

  • Misturar segundos e milissegundos. Este é o clássico erro "off-by-1000". É o bug mais comum ao se trabalhar com timestamps. Como regra geral: 10 dígitos são segundos, 13 dígitos são milissegundos. Se você vir algo diferente, desconfie bastante.

  • Ignorar o problema de 2038. Se você está construindo uma aplicação web padrão em uma linguagem moderna, provavelmente está seguro. Mas se você está escrevendo código C para um dispositivo IoT embarcado, um sistema de infotainment de carro, ou mantendo um sistema legado de 32 bits, o bug Y2038 é uma bomba-relógio bem real.

  • Usar strings ambíguas para gerar timestamps. Criar um timestamp a partir de uma string como "15 de março de 2025 22:00" é pedir por problemas. Isso é no seu fuso horário local? No fuso horário do servidor? UTC? Sempre gere timestamps a partir de objetos que reconhecem fusos horários ou use strings UTC explícitas (como o formato ISO 8601: 2025-03-15T22:00:00Z).

Por que isso deve estar no seu radar

Você simplesmente não pode ser um desenvolvedor moderno sem entender o Epoch time. É a língua franca do tempo na computação. Você vai encontrá-lo em todos os lugares:

  • APIs: Payloads JSON o usam constantemente para campos como createdAt, updatedAt e expires_at.
  • JWTs: As claims exp (expiração), iat (emitido em) e nbf (não antes de) são todas timestamps Unix padrão.
  • Bancos de dados: Armazenar o tempo como um único inteiro é muitas vezes mais eficiente para indexação e armazenamento do que usar um tipo complexo como DATETIME.
  • Arquivos de Log: Usar timestamps numéricos torna trivial correlacionar eventos entre dezenas de servidores e serviços diferentes, mesmo que estejam em fusos horários distintos.
  • Sistemas de Arquivos: A maioria dos sistemas de arquivos armazena as datas de criação e modificação de arquivos como timestamps Unix.

Entender como ele funciona permite que você depure toda uma classe de bugs complicados relacionados ao tempo com confiança. Permite que você atravesse o mundo humano bagunçado de fusos horários e calendários e pense sobre o tempo da maneira que um computador faz: como uma linha simples e ordenada de números.

Aprofunde-se

Teoria feita. Hora de pôr a mão na massa — 100% no seu navegador.

Testar a ferramenta: Conversor de Época