Unix timestamp, ISO 8601 e fusos: domando datas no código

O que é o Unix epoch

Todo computador precisa de uma forma única e sem ambiguidade de marcar um instante no tempo. A solução que o Unix adotou nos anos 70 e que hoje move quase tudo — bancos de dados, APIs, logs, sistemas operacionais — é simples até o constrangimento: contar quantos segundos se passaram desde um marco fixo. Esse marco se chama epoch, e é meia-noite de 1º de janeiro de 1970, no fuso UTC.

Um Unix timestamp é só essa contagem. O número 0 é exatamente 1970-01-01 00:00:00 UTC. O número 1.000.000.000 (um bilhão de segundos) caiu em 9 de setembro de 2001. E o número que aparece nos sistemas neste exato momento tem dez dígitos, na casa de 1,75 bilhão.

A grande vantagem é que o timestamp é um inteiro só: sem fuso, sem formato de data, sem "qual é o dia e qual é o mês". O instante "agora" tem o mesmo timestamp no Japão, na Bahia e em Marte. O que muda de lugar para lugar é apenas como cada relógio resolve exibir aquele número.

Vale um exemplo na mão. Um dia tem 86.400 segundos (24 × 60 × 60). Pegue o timestamp 90061. Repare que 90061 = 86.400 + 3.600 + 60 + 1, ou seja, 1 dia, 1 hora, 1 minuto e 1 segundo depois do epoch. Logo, 90061 corresponde a 1970-01-02 01:01:01 UTC. É essa aritmética de divisão por 86.400, depois por 3.600, depois por 60, que o Conversor de Timestamp faz por você nos dois sentidos — de número para data legível e de volta.

Segundos vs milissegundos (a confusão clássica)

Aqui mora o bug mais comum de quem mexe com datas. Existem dois mundos. O Unix tradicional, e linguagens como C, Python, PHP e Go, contam o timestamp em segundos. Já o JavaScript — onde Date.now() e getTime() são o padrão — devolve a contagem em milissegundos. Então o mesmo instante pode aparecer como 1719705600 (segundos) ou 1719705600000 (milissegundos).

O acidente acontece quando os dois se misturam. No JavaScript, escrever new Date(1719705600) interpreta o número como milissegundos e te joga para vinte dias depois do epoch — janeiro de 1970, não 2024. O certo seria new Date(1719705600000) ou new Date(1719705600 * 1000). No sentido inverso, mandar milissegundos para uma função que espera segundos te lança milhares de anos no futuro.

O jeito mais rápido de saber em que unidade um número está é contar os dígitos:

Regra de bolso: se o número está na casa de 1,7 bilhão, são segundos; se está na casa de 1,7 trilhão, são milissegundos. Os dez dígitos dos segundos, aliás, valem até o ano 2286 — não vão te trair tão cedo. Quando bater a dúvida, cole o número no conversor: se a data sair como "1970" ou como um ano absurdo lá na frente, você errou a unidade por um fator de mil.

ISO 8601: o formato sem ambiguidade

Escreva 03/04/2026 e metade do planeta lê "3 de abril" enquanto a outra metade lê "4 de março". Essa briga entre dd/mm e mm/dd já quebrou integração, atrasou voo e bagunçou planilha. A norma ISO 8601 existe justamente para acabar com isso.

A regra é escrever do maior para o menor — ano, mês, dia, hora — sempre com zeros à esquerda:

• 2026-06-30 — só a data.
• 2026-06-30T14:30:00Z — data e hora. O T separa a data da hora; o Z (lê-se "Zulu") significa UTC, deslocamento zero.
• 2026-06-30T11:30:00-03:00 — o mesmo instante, escrito no horário de Brasília (UTC−3). Repare: 11:30 em Brasília mais 3 horas dá 14:30 em UTC.

Além de não ter ambiguidade, o formato tem um bônus precioso: como ele é "big-endian" (componente mais significativo primeiro), ordenar essas strings em ordem alfabética já as coloca em ordem cronológica. Isso vale ouro em nomes de arquivo, chaves de banco e logs. O perfil mais usado em APIs é o RFC 3339, uma versão um pouco mais estrita do ISO 8601 — é o que você vê em quase todo JSON de back-end moderno.

Quando o que você tem é uma data no formato brasileiro e precisa dela em ISO (ou o contrário), o Conversor de Formato de Data faz a ponte entre dd/mm/aaaa, ISO 8601 e outros padrões sem você ter que decorar máscaras.

A semana também tem norma

O ISO 8601 vai além da data: ele define como numerar as semanas do ano. A semana começa na segunda-feira, e a semana 1 é aquela que contém a primeira quinta-feira do ano (de forma equivalente, a que contém o dia 4 de janeiro). Por isso os primeiros dias de janeiro às vezes pertencem à semana 52 ou 53 do ano anterior. É uma convenção que confunde quem não a conhece — relatórios financeiros e sistemas de produção vivem disso. Para descobrir em que semana ISO uma data cai, use o Número da Semana ISO.

UTC, fusos e o pesadelo do horário de verão

UTC (Tempo Universal Coordenado) é a referência mundial, a régua a partir da qual todos os fusos são deslocamentos. Mas é preciso separar dois conceitos que a vida cotidiana mistura: deslocamento não é a mesma coisa que fuso horário.

O deslocamento é um número fixo, tipo −03:00. O fuso horário é uma região com regras que mudam no tempo — por exemplo, America/Sao_Paulo. A diferença é crucial: o Brasil aboliu o horário de verão em 2019, então hoje São Paulo fica em UTC−3 o ano inteiro. Mas, antes disso, no verão os relógios iam para UTC−2. Um deslocamento fixo não captura essa história; o nome do fuso, sim.

Daí vem o pesadelo do horário de verão para quem programa. Quando o relógio "adianta" na primavera, existe um horário local que simplesmente não existe (o relógio pula das 23:59 para as 01:00). Quando "atrasa" no outono, existe um horário local que acontece duas vezes — e aí "01:30" daquele dia é ambíguo. Agendar um lembrete ou calcular uma diferença em cima dessas bordas é fonte infinita de bug.

A boa prática que resolve quase tudo cabe em três frases:

1. Guarde o instante sempre em UTC (ou como Unix timestamp, que já é UTC por definição).
2. Converta para o horário local só na hora de exibir para o usuário.
3. Para o fuso, use os nomes do banco IANA (America/Sao_Paulo, Europe/Lisbon), nunca deslocamentos fixos — porque as regras de horário de verão mudam por decisão política e o banco IANA é atualizado para acompanhar.

O bug do ano 2038

O timestamp é um número, e número precisa de espaço para ser guardado. Muitos sistemas antigos armazenam o tempo Unix em um inteiro de 32 bits com sinal. O maior valor que esse tipo comporta é 2.147.483.647 (isto é, 2³¹ − 1). Convertendo: esse número de segundos esgota exatamente em 19 de janeiro de 2038, às 03:14:07 UTC.

Um segundo depois disso, o contador "estoura" e vira negativo, jogando a data de volta para 13 de dezembro de 1901. É o mesmo tipo de problema do bug do milênio (Y2K), só que com causa diferente: ali era o ano de dois dígitos; aqui é o limite de um inteiro de 32 bits.

A correção já está em curso há anos e é direta: usar inteiros de 64 bits, que empurram o limite para algo como 292 bilhões de anos — tempo de sobra. Sistemas operacionais, linguagens e bancos modernos já fazem isso. O risco real fica em sistemas embarcados antigos, formatos de arquivo legados e colunas de banco de dados criadas lá atrás com o tipo de 32 bits. Se você mantém algo do tipo, 2038 é um prazo de fato — só que distante o bastante para ser planejado com calma.

Perguntas frequentes

O Unix timestamp muda quando eu troco de fuso horário?

Não. O timestamp representa um instante absoluto e é sempre referenciado a UTC. Trocar de fuso muda apenas a data e a hora exibidas, nunca o número por baixo. Por isso ele é tão usado para guardar "quando" algo aconteceu: dois servidores em continentes diferentes registram o mesmo evento com o mesmo timestamp.

Como sei se um timestamp está em segundos ou milissegundos?

Conte os dígitos. Para datas atuais, dez dígitos são segundos (na casa de 1,7 bilhão) e treze são milissegundos (1,7 trilhão). Se converter e a data cair em 1970 ou num ano impossível no futuro, você errou a unidade por um fator de mil.

ISO 8601 e RFC 3339 são a mesma coisa?

Quase. O RFC 3339 é um perfil mais restrito do ISO 8601, pensado para a internet: exige o separador T, exige o deslocamento de fuso (Z ou ±hh:mm) e proíbe algumas formas exóticas que o ISO permite. Na prática, se você escrever 2026-06-30T14:30:00Z, está válido nos dois.

O que significa o "Z" no final de uma data?

É o deslocamento zero — ou seja, UTC. Vem da notação militar de fusos, em que UTC é a zona "Zulu". 2026-06-30T14:30:00Z é idêntico a 2026-06-30T14:30:00+00:00.

O bug de 2038 vai derrubar a internet?

Não no sentido catastrófico. A maioria esmagadora dos sistemas em uso já migrou para inteiros de 64 bits. O cuidado fica com equipamentos embarcados antigos e bases de dados legadas que ainda guardam o tempo em 32 bits — esses precisam ser identificados e atualizados antes de janeiro de 2038.