O problema do ano 2038 (Y2K38) explicado

O que é o problema do ano 2038?

Os timestamps Unix são tradicionalmente armazenados como um inteiro com sinal de 32 bits que conta os segundos desde 1 de janeiro de 1970 00:00:00 UTC. O valor máximo de um inteiro com sinal de 32 bits é 2,147,483,647, que corresponde a 19 de janeiro de 2038 às 03:14:07 UTC. Um segundo depois, o inteiro estoura para -2,147,483,648. Interpretado como timestamp Unix, esse valor negativo corresponde a 13 de dezembro de 1901, jogando os sistemas afetados quase 137 anos para o passado.

Os valores do estouro

• 2^31 − 1 = 2,147,483,647 (inteiro com sinal de 32 bits máximo)
• 2,147,483,647 como data = 19 de janeiro de 2038 03:14:07 UTC
• 2,147,483,647 + 1 estoura para −2,147,483,648 (o valor de 32 bits mais negativo)
• −2,147,483,648 como data = 13 de dezembro de 1901 20:45:52 UTC

Quais sistemas estão em risco?

O problema afeta sistemas que armazenam timestamps como inteiros com sinal de 32 bits:

• Sistemas embarcados e microcontroladores com time_t de 32 bits
• Código C e C++ legado compilado para alvos de 32 bits usando time_t ou int para timestamps
• Kernels Linux antigos (anteriores ao 5.6) em hardware de 32 bits ainda em produção
• Colunas TIMESTAMP do MySQL — limitadas a 2038-01-19; use DATETIME no lugar
• Alguns protocolos de rede e formatos de arquivo que codificam timestamps como valores de 32 bits
• Firmware em sistemas de controle industrial e dispositivos IoT com vida útil de décadas

Quais sistemas são seguros?

A maior parte do código e da infraestrutura modernos já não é afetada:

• Qualquer SO de 64 bits — Linux (glibc 2.34+ também corrige hardware de 32 bits), macOS, Windows
• Python — timestamps usam floats de 64 bits, seguros muito além do ano 292 milhões
• JavaScript — Date usa floats IEEE 754 de 64 bits, seguro até o ano 275,760
• Go e Rust — usam int64 para tempo internamente, seguros por bilhões de anos
• Java — java.time.Instant usa long (64 bits), seguro até o ano ~292 milhões
• PostgreSQL TIMESTAMP — armazena datas além de 2038 corretamente
• MySQL DATETIME — faixa 1000-01-01 a 9999-12-31, não afetado

FAQ do problema do ano 2038

O que é o problema do ano 2038?

O problema do ano 2038 (Y2K38) é um bug em que sistemas que usam inteiros com sinal de 32 bits para armazenar timestamps Unix vão estourar em 19 de janeiro de 2038 às 03:14:07 UTC. O valor máximo de um inteiro com sinal de 32 bits é 2,147,483,647. Um segundo depois, o inteiro vira -2,147,483,648, que corresponde a 13 de dezembro de 1901.

Qual é o timestamp Unix de 19 de janeiro de 2038?

O timestamp Unix de 19 de janeiro de 2038 às 03:14:07 UTC é 2,147,483,647 — o valor máximo de um inteiro com sinal de 32 bits (2^31 - 1). É o momento exato em que ocorre o estouro do ano 2038 em sistemas de 32 bits.

Y2K38 é o mesmo que Y2K?

Não. O Y2K (problema do ano 2000) era causado por programas que armazenavam anos com 2 dígitos. O Y2K38 é causado por armazenar timestamps Unix como inteiros com sinal de 32 bits que estouram em 2038. Causas diferentes, sistemas afetados diferentes.

A internet vai quebrar em 2038?

Provavelmente não de forma significativa. A maior parte da infraestrutura da internet já migrou para sistemas de 64 bits. O risco se concentra em sistemas embarcados, dispositivos IoT legados e software sem atualização há décadas. Sistemas operacionais, linguagens e bancos de dados modernos já são seguros.