GeradoresOnline

Timestamp Unix e o problema do ano 2038

O que é o timestamp Unix, como converter segundos e milissegundos em data e por que inteiros de 32 bits deixam de funcionar em 2038.

Por Equipe L9 · Publicado em 23/09/2026 · 4 min de leitura

O timestamp Unix é a forma mais comum de representar um instante no tempo em sistemas de computador: um único número, sem fuso horário, sem formatação, fácil de guardar, comparar e ordenar. Esse mesmo número esconde uma armadilha que tem data marcada: o dia 19 de janeiro de 2038. Este guia explica o que o timestamp é, como interpretá-lo e por que o problema de 2038 já afeta sistemas hoje.

Definição

O timestamp Unix (ou "Unix time", "epoch time") é a quantidade de segundos decorridos desde 1970-01-01 00:00:00 UTC, o chamado epoch. Alguns exemplos reais:

0             →  1970-01-01 00:00:00 UTC
1000000000    →  2001-09-09 01:46:40 UTC
1700000000    →  2023-11-14 22:13:20 UTC
2147483647    →  2038-01-19 03:14:07 UTC

Como o valor é sempre em UTC, ele é o mesmo em qualquer lugar do mundo. O horário local só entra na hora de exibir ao usuário. Para converter valores nos dois sentidos, use o conversor de timestamp Unix.

Segundos ou milissegundos?

A confusão mais frequente ao ler um timestamp é a unidade. O Unix tradicional usa segundos e, atualmente, tem 10 dígitos (por exemplo, 1700000000). Já o JavaScript (Date.now()) e várias APIs usam milissegundos, com 13 dígitos (1700000000000). Interpretar um valor em milissegundos como se fosse em segundos resulta em uma data absurda, no futuro distante; interpretar segundos como milissegundos resulta em uma data em janeiro de 1970. Ao depurar, contar os dígitos costuma resolver na hora.

Detalhes que pegam desprevenido

  • Valores negativos: instantes anteriores a 1970 são representados por números negativos.
  • Segundos bissextos: o tempo Unix os ignora, contando cada dia como exatamente 86.400 segundos. Isso simplifica contas de duração, mas significa que o timestamp não mede segundos físicos de forma contínua.
  • Fuso horário: o timestamp não tem fuso. Erros de fuso aparecem quando alguém converte para data sem informar qual fuso usar. Para comparar horários entre regiões, veja o conversor de fuso horário.

O problema do ano 2038

Durante décadas, o timestamp foi guardado em um inteiro de 32 bits com sinal. Esse tipo vai de −2.147.483.648 até 2.147.483.647, isto é, de −231 a 231 − 1. O maior valor positivo, 2147483647, corresponde a 19 de janeiro de 2038, às 03:14:07 UTC.

No segundo seguinte, o contador estoura: o valor "dá a volta" para o menor número negativo, −2147483648, que representa 1901-12-13 20:45:52 UTC. Um sistema afetado passa a acreditar que estamos em 1901, e tudo que depende de datas (agendamentos, certificados, validade de sessões, ordenação de registros) pode falhar. É o mesmo tipo de problema do "bug do milênio", porém causado pelo limite de um tipo numérico, não pela representação do ano em dois dígitos.

Por que isso já importa hoje

Faltando pouco mais de uma década, o problema já aparece em sistemas que calculam datas futuras. Um contrato de 20 ou 30 anos, uma data de validade, um certificado de longa duração ou um agendamento de manutenção cujo instante final ultrapassa 2038 não cabe em 32 bits com sinal. Ou seja, o defeito se manifesta anos antes do dia do estouro.

Os pontos mais expostos são:

  • Sistemas embarcados e equipamentos industriais com vida útil longa e firmware raramente atualizado.
  • Formatos de arquivo e protocolos antigos que reservaram 32 bits para a data.
  • Bancos de dados com colunas inteiras de 32 bits guardando timestamps. Em particular, o tipo TIMESTAMP do MySQL tem esse limite; para datas além de 2038, a alternativa é usar DATETIME.
  • Código em linguagens de baixo nível que ainda declara o tempo como int de 32 bits.

Como se proteger

  1. Use inteiros de 64 bits para guardar timestamps. Sistemas operacionais e linguagens modernas já fazem isso por padrão; o limite passa a ser de cerca de 292 bilhões de anos.
  2. Revise colunas de banco de dados que guardam datas em inteiros ou tipos com limite em 2038.
  3. Teste seu sistema com datas posteriores a 2038 (por exemplo, criando um registro com validade em 2050) antes que isso vire um incidente.
  4. Ao calcular prazos longos, use as bibliotecas de data da linguagem em vez de somar segundos manualmente. Para contas simples de dias entre datas, o contador de dias entre datas ajuda a conferir o resultado.

Ferramentas relacionadas

Continue lendo

Gostou das ferramentas? Ajude a manter o site no ar: apoiar via Pix · Sobre · Contato · Política de Privacidade