Unix timestamp

Um Unix timestamp (ou tempo POSIX, ou segundos desde a época) é o número de segundos decorridos desde 1970-01-01 00:00:00 UTC, ignorando segundos bissextos. Em 2026-05-16, o Unix timestamp é aproximadamente 1.779.000.000.

Por que esse formato domina a computação:

• É um único inteiro. Nenhuma ambiguidade de fuso horário, calendário, localidade ou horário de verão embutida.
• A aritmética de tempo é trivial — subtraia dois timestamps para obter uma duração em segundos.
• Ordenável como números. Índices de banco de dados e consultas de séries temporais não precisam de comparadores sofisticados.
• Compacto no armazenamento e na transmissão.

Três variantes que você encontrará:

• Segundos. O original. 1700000000 = 14 Nov 2023 22:13:20 UTC.
• Milissegundos. O Date.now() do JavaScript retorna isso. Multiplique o valor em segundos por 1000.
• Microssegundos / nanossegundos. Telemetria de alta resolução, rastreamentos distribuídos. O timestamptz do Postgres armazena microssegundos.

Dois problemas bem conhecidos:

• Ano 2038 (Y2K38). Um inteiro de 32 bits com sinal de segundos transborda em 2038-01-19 às 03:14:07 UTC. Sistemas modernos usam 64 bits (bom para ~292 bilhões de anos); sistemas embarcados legados podem não.
• Segundos bissextos. UTC insere segundos bissextos ocasionais para se manter sincronizado com a rotação da Terra. O tempo Unix os ignora — o timestamp no instante do segundo bissexto é ambíguo. A maioria dos sistemas de produção usa um smear (Google, AWS) que distribui o segundo bissexto ao longo de horas.

Converta Unix timestamps em datas legíveis (e de volta) alimentando-os em uma biblioteca de datas. A conversão para um horário de relógio sempre requer uma escolha de fuso horário — o mesmo instante é “15h em NYC” e “meia-noite em Tóquio” dependendo de qual fuso você exibe. Veja nosso conversor de fuso horário.

Como os sistemas operacionais estão migrando do time_t de 32 bits: o Linux adotou time_t de 64 bits como ABI padrão do kernel em 2020 (kernel 5.6+) e a glibc 2.32 (2020) o expôs ao espaço do usuário. O NetBSD fez a mudança em 2012, o OpenBSD em 2014. O FreeBSD seguiu em 2024. As superfícies restantes com atraso são sistemas embarcados rodando kernels mais antigos fixados, certos protocolos on-chain que codificaram timestamps de 32 bits em seu formato de wire (o header de bloco do Bitcoin inclui um Unix timestamp de 32 bits, problemático por volta de 2106 quando ocorreria o transbordamento sem sinal), e formatos de arquivo legados (arquivos ZIP usam timestamps DOS de 32 bits com uma época de 1980; tar usa timestamps Unix de 32 bits). O trabalho difícil é encontrar e corrigir esses; o lado do kernel está amplamente concluído. Referência: POSIX.1-2017 §4.16 — Segundos desde a Época.

Exemplo prático

Converta 1700000000 para uma data legível por humanos em UTC. Divida e aplique módulo a partir de segundos: 1.700.000.000 / 86400 = 19.675,93 dias desde 1970-01-01. O dia 19.675 é 2023-11-14 (aritmética de calendário). A fração 0,93 de um dia × 86.400 = 80.000 segundos = 22:13:20. Então 1700000000 = 2023-11-14T22:13:20Z. Verifique em JavaScript: new Date(1700000000 * 1000).toISOString() → "2023-11-14T22:13:20.000Z". Para exibir em Tóquio (UTC+9): adicione 9 horas = 2023-11-15T07:13:20+09:00. O mesmo instante, relógio diferente. O bug clássico: armazenar new Date().getTime() (milissegundos) em uma coluna que o restante do código trata como segundos — cada timestamp acaba sendo lido como o ano 55.000+ quando exibido.

Quando e por que isso importa

Sempre que dois sistemas trocam dados de tempo — frontend para backend, banco de dados para pipeline ETL, microsserviço para microsserviço — Unix timestamps são a única representação que não carrega ambiguidade de fuso horário, localidade, calendário ou horário de verão. Armazene timestamps como segundos Unix ou milissegundos em uma coluna de 64 bits, formate para ISO-8601 com fuso horário explícito apenas na borda para exibição humana. O hábito defensivo: em cada coluna ou campo de API que carrega tempo, codifique a unidade (created_at_ms, expires_at_unix_seconds) para que um revisor de código não possa confundir a ordem de magnitude. O risco Y2038 é pequeno para novos sistemas, mas real para qualquer timestamp de 32 bits em formatos de wire de protocolo e sensores embarcados — audite-os agora enquanto há 12 anos de margem, não em 2037 quando os patches forem urgentes. Referência: RFC 3339 — Data e Hora na Internet.