Tempo Unix é o encanamento sob quase todo timestamp que você toca: o created_at de banco, a expiração de um JWT, a hora de uma linha de log, a data de modificação de um arquivo, os cabeçalhos HTTP. Apesar de onipresente, tem peculiaridades que surpreendem desenvolvedores todo ano — segundos vs milissegundos, armadilhas de fuso, o transbordamento que se aproxima em 2038. Este guia cobre o que realmente é e como trabalhar com ele com segurança.

O que é

Tempo Unix é a contagem de segundos decorridos desde 00:00:00 UTC em 1 de janeiro de 1970, chamado epoch Unix. Todo instante no tempo vira um único inteiro — uma reta numérica ancorada em 1970 que se estende para frente (positivo) e, menos útil, para trás (negativo). Hoje, tempo Unix gira em torno de 1,78 bilhão e subindo.

Por que 1970

Unix estava em desenvolvimento nos Bell Labs quando o time precisou de um ponto zero para as novas funções de tempo. Os candidatos óbvios — um ano historicamente significativo, um século redondo — vinham com bagagem. A escolha pragmática: uma data recente e redonda, 1 de janeiro de 1970 às 00:00:00 UTC. Nada de especial aconteceu nesse dia. O valor era estar perto o suficiente de "agora" para manter os números pequenos e longe o suficiente para que arquivos existentes não precisassem de timestamps negativos.

Segundos ou milissegundos

O tempo Unix original é em segundos. Todo sistema POSIX — Linux, macOS, bancos, time.time() do Python convertido para int — retorna segundos. Mas o JavaScript escolheu milissegundos quando Date.now() foi especificado em 1995, e a maioria das APIs modernas (Java, stdlib do Go, formatos ISO, bancos modernos) seguiu. Resultado: duas convenções convivendo. Um timestamp de 10 dígitos é quase sempre segundos; um de 13 dígitos, milissegundos. Ao montar uma integração, verifique em que lado o outro sistema está — bugs de misturar são silenciosos e produzem datas com 53 anos de diferença.

Fusos horários e o que tempo Unix realmente representa

Tempo Unix é sempre UTC. Ele não conhece fusos. Quando um log diz "criado 1712345678", é um ponto exato em tempo global — convertê-lo para string legível é onde o fuso entra. É, na verdade, uma virtude: seus servidores, usuários e bancos podem renderizar o mesmo instante em suas horas locais sem nunca discordarem sobre quando.

O problema Y2038

Em 19 de janeiro de 2038 às 03:14:07 UTC, um inteiro de 32 bits com sinal guardando segundos Unix transborda. O segundo seguinte salta para um número negativo, interpretado como 13 de dezembro de 1901. Qualquer sistema que ainda armazene tempo Unix em int32 vê datas embaralharem. Dispositivos embarcados, formatos binários antigos e programas C de longa duração são o risco principal — sua aplicação web quase certamente está bem, porque toda linguagem e banco mainstream migrou para 64 bits há muito. Um timestamp Unix de 64 bits não transborda antes de ~292 bilhões de anos.

Por que ainda domina

Qualquer outro formato de timestamp precisa de fuso, sistema de calendário ou parser para fazer sentido. Tempo Unix é um único número, interpretável sem contexto, ordenável sem parsear, compacto em armazenamento, barato de comparar. Seus descendentes — ISO 8601 e RFC 3339 para exibição, relógios monotônicos para medir tempo decorrido — cobrem o que ele sozinho não cobre. Mas para "em que instante global isso aconteceu", a epoch de 1970 venceu e dificilmente será substituída.