Marca de tempo Unix explicada: segundos, milissegundos, fusos horários e 2038

Abra quase qualquer arquivo de log, tabela de banco de dados ou resposta API e você encontrará números como 1760000000. Isso é um selo de tempo do Unix: o número de segundos decorridos desde 00:00:00 UTC em 1 de janeiro de 1970, conhecido como a época do Unix. É a forma mais comum de os computadores representarem um momento no tempo, e entendê-lo evita toda uma classe de bugs envolvendo fusos horários, verão e análise de datas.

Porquê contar segundos a partir de 1970?

Os primeiros desenvolvedores do Unix precisavam de uma representação simples e compacta do tempo. Contar segundos a partir de uma data recente fixa encaixava em um único número inteiro, era fácil de comparar e subtrair e evitava a complexidade dos calendários. A data de 1o de janeiro de 1970 era simplesmente um ponto de partida conveniente quando o Unix estava sendo construído.

As vantagens ainda são válidas:

• ** Independente do fuso horário.** Um carimbo de hora identifica um instante, não uma leitura de relógio de parede. O mesmo evento tem o mesmo carimbo horário em Tóquio, Berlim e São Paulo.
• Aritmética fácil. A diferença entre dois carimbos de tempo é uma duração em segundos. Adicionando 86.400 movimentos para frente num dia.
• ** Compacto e classificável.** Um inteiro leva 8 bytes e classifica cronologicamente.
• Não há confusão entre 03/04 significando 4 de março ou 3 de abril.

Segundos versus milissegundos

O erro mais frequente é misturar unidades:

• Ferramentas Unix, a maioria dos bancos de dados, JWT e muitas APIs usam segundos: 10 dígitos hoje, como 1760000000.
• O Date.now() do JavaScript, o System.currentTimeMillis() do Java e muitos sistemas de análise usam milissegundos: 13 dígitos, como o 1760000000000.
• Alguns sistemas usam microssegundos (16 dígitos) ou nanosegundos (19 dígitos).

Interpretando milissegundos como segundos, obtemos uma data dezenas de milhares de anos no futuro; o inverso leva-nos a janeiro de 1970. Se alguma vez vir "1970-01-21" numa interface, alguém passou segundos onde se esperava milissegundos. Um [conversor de carimbo horário] ((/tools/timestamp) detecta a unidade por comprimento, que é uma verificação rápida da sanidade.

Conversão de carimbos horários em línguas comuns

JavaScript

const nowSeconds = Math.floor(Date.now() / 1000);
const date = new Date(1760000000 * 1000);
date.toISOString(); // "2025-10-09T08:53:20.000Z"

Python

import time, datetime
now = int(time.time())
dt = datetime.datetime.fromtimestamp(1760000000, tz=datetime.timezone.utc)

Sempre passe tz= no Python; sem ele, fromtimestamp retorna um tempo local ingênuo que é fácil de interpretar mal.

**SQL (PostgreSQL) **

SELECT to_timestamp(1760000000);           -- timestamptz
SELECT extract(epoch FROM now())::bigint;  -- current Unix time

Vai-te embora.

t := time.Unix(1760000000, 0).UTC()
now := time.Now().Unix()

• Concha *

date +%s                    # current timestamp
date -u -d @1760000000      # GNU date
date -u -r 1760000000       # macOS/BSD date

Fusões horárias: armazenar UTC, exibir local

Uma marca de tempo não tem fuso horário; é um instante absoluto. Problemas surgem ao converter para e de datas legíveis por humanos:

• ** Parseando uma data sem uma zona.** new Date("2026-03-29 02:30") é interpretado no fuso horário local de qualquer máquina que execute o código. Em um servidor em UTC e um laptop em Berlim, ele produz selos de tempo diferentes.
• Falhas e sobreposições de verão. Nas zonas com horário de verão, alguns horários locais não existem (os relógios avançam) e outros ocorrem duas vezes (os relógios recuam). Uma marca de tempo não tem essa ambigüidade.
• ** Armazenando horários locais.** Se você armazenar "2026-11-01 01:30" sem uma zona, você nunca pode ter certeza de que momento foi.

Regra geral: armazenar e transmitir marcas de tempo ou cadeias ISO 8601 com deslocamento explícito (2026-10-11T09:30:00Z ou +02:00). Converter para a zona local do utilizador somente quando exibido. Armazenar o nome do fuso horário IANA do usuário (como Europe/Berlin) separadamente se você precisar agendar as coisas em seu horário local.

ISO 8601 versus marcas de tempo do Unix

As cadeias ISO 8601 como 2026-10-11T09:30:00Z são lidas por humanos e também são inequívocas quando incluem Z ou um deslocamento. Muitas APIs as preferem por legibilidade. Os carimbos de tempo do Unix são menores e mais rápidos de comparar. Ambos estão bem; o importante é a consistência e sempre incluir informações de zona.

Segundos bissextos

A rotação da Terra é ligeiramente irregular, de modo que o UTC oficial ocasionalmente insere um segundo bissexto. O tempo do Unix ignora-os: todos os dias são exatamente 86.400 segundos, e durante um segundo bissexto o selo de tempo se repete ou é borrado. Para quase todas as aplicações, isto é invisível. Se você trabalha em cronometragem de alta precisão, use o tempo TAI ou GPS em vez disso. Os órgãos internacionais de cronometragem decidiram eliminar gradualmente os segundos bissextos até 2035, o que tornará isso ainda menos preocupante.

O problema do ano 2038

Muitos sistemas mais antigos armazenam o tempo Unix como um inteiro assinado de 32 bits, cujo valor máximo é 2.147.483.647. Isso corresponde a 03:14:07 UTC em 19 de janeiro de 2038. Um segundo depois, o valor transborda para −2.147.483.648, o que representa 13 de dezembro de 1901.

Os sistemas operacionais modernos de 64 bits, línguas e bancos de dados usam carimbos de tempo de 64 bits, que não se sobrecarregarão por cerca de 292 bilhões de anos. Os riscos continuam a ser:

• Dispositivos incorporados e controladores industriais com longa vida útil.
• Formatos de ficheiros e protocolos de rede com campos de tempo de 32 bits.
• Colunas de base de dados declaradas como 32 bits INT com segundos de época. O tipo TIMESTAMP do MySQL tem um limite de 2038; DATETIME ou BIGINT não.

Verifique dados de longa duração agora, especialmente qualquer coisa que armazene datas futuras como o prazo de validade de certificados ou contratos de 20 anos.

Horários negativos

As datas anteriores a 1970 têm carimbos negativos. -86400 é 31 de Dezembro de 1969. A maioria das linguagens modernas lidam com eles corretamente, mas algumas APIs e planilhas mais antigas não, então teste datas históricas explicitamente.

Lista de verificação prática de depuração

1. Conta os dígitos: 10 para segundos, 13 para milissegundos.
2. Converte para UTC primeiro, depois para hora local, para separar bugs de unidade de bugs de zona.
3. Verifique se uma cadeia de datas inclui Z ou um deslocamento antes de analisá-la.
4. Compare relógios de servidor e cliente se os tokens ou assinaturas falharem com erros "expirados" ou "ainda não válidos" veja como funciona JWT para saber por que exp e nbf são segundos Unix.
5. Ao agendar tarefas recorrentes, lembre-se de que o cron é executado na zona do servidor; [estes exemplos de cron] (/blog/cron-expression-examples) cobrem os detalhes.

Resumo

Um selo de tempo Unix é o número de segundos desde 1970-01-01 UTC. É simples, independente do fuso horário e fácil de calcular. A maioria dos bugs vem de misturar segundos e milissegundos, analisar datas sem zonas, ou armazenar horas locais. Armazenar UTC, converter nas bordas, usar números inteiros de 64 bits, e você raramente terá que pensar sobre o tempo novamente.