Você provavelmente se lembra do pânico em torno do Y2K. A mídia teve um dia de campo prevendo o colapso global quando o relógio bateu o ano 2000. Mas, embora muitos sistemas legados tenham sido corrigidos naquela época, um cronômetro diferente ainda está correndo no fundo de grande parte da Internet moderna. É chamado de problema do ano 2038. E está enraizado na forma como as linguagens de programação C lidam com o tempo.
A maioria das pessoas presume que o problema gira em torno de anos de dois dígitos, como o ano 2000. Não é. A questão central está mais profunda no código. Especificamente, como os programas C armazenam dados de data.
O limite de 32 bits
Aqui está a realidade técnica. A biblioteca de tempo padrão em C usa um número inteiro assinado de 4 bytes para rastrear o tempo. São 32 bits. Este formato define o “horário da época” como começando em 1º de janeiro de 1970, às 12h00 UTC. Cada segundo após esse momento é armazenado como um número simples.
Por exemplo, o carimbo de data/hora 919642718 representa 919 milhões de segundos após a época. Isso ocorre em 21 de fevereiro de 1999. É conveniente porque subtrair um carimbo de data/hora de outro fornece os segundos exatos entre dois eventos. As bibliotecas então convertem esses segundos em minutos, horas ou anos.
Mas há um teto rígido.
Um inteiro assinado de 32 bits tem um valor máximo de 2.147.483.647. Assim que o contador atingir zero segundos após 1º de janeiro de 1970, ele será revertido.
Essa rolagem acontece em 19 de janeiro de 2038.
Após essa data, o inteiro transborda. Ele muda para um número negativo. Para um sistema que depende deste formato, esse valor negativo é uma data inválida. É efetivamente uma falha na matriz de qualquer software que não tenha sido atualizado.
Por que isso é mais fácil que o ano 2000
A boa notícia? Consertar isso não é tão complicado quanto os pesadelos dos mainframes do final dos anos 90.
No Y2K, muitos sistemas não padronizaram a forma como armazenavam as datas. Alguns usaram MM-DD-AA. Outros usaram AA-MM-DD. A falta de um formato universal significava que os desenvolvedores tinham que procurar o código em cada aplicativo e alterar manualmente a lógica de data.
O problema do ano 2038 é mais limpo.
A biblioteca de horário padrão encapsula todo o processo de cronometragem. Ele define seus próprios tipos e funções. Assim, programas bem escritos podem simplesmente ser recompilados. Os engenheiros só precisam trocar a biblioteca por uma versão que use um tamanho de byte maior.
Por exemplo, passar de um número inteiro de 4 bytes para um número inteiro de 8 bytes expande o intervalo significativamente. Um número inteiro assinado de 8 bytes pode contar muito além de 2038 sem estourar. É uma atualização de software. Não é uma substituição de hardware. Não é uma reescrita de código. Uma troca de biblioteca.
Windows e Mac: temporizadores diferentes, problemas diferentes
Nem todo sistema usa o formato C de 32 bits. Diferentes sistemas operacionais têm suas peculiaridades.
O Windows NT, por exemplo, usa um número inteiro de 64 bits. Ele rastreia o tempo em incrementos de 100 nanossegundos. Mas começa a contar a partir de 1º de janeiro de 1601, e não de 1970. Isso adia muito mais a data de transbordamento. O Windows provavelmente atingirá seu limite por volta do ano 2184.
A Apple adotou uma abordagem diferente. De acordo com documentação da própria Apple, o macOS está estruturado para permanecer válido até o ano 29.940. Isso é cerca de 27.000 anos a partir de agora. Portanto, se você estiver em um Mac, não precisa se preocupar com o travamento do seu calendário em 2038.
Quem mais está em risco?
Os sistemas baseados em Unix são a principal preocupação. Mas eles não estão sozinhos.
Os sistemas embarcados também são vulneráveis. Muitos dispositivos IoT, controladores industriais e servidores de banco de dados mais antigos dependem do mesmo formato de hora de 32 bits. Se não forem atualizados, começarão a interpretar mal as datas após 19 de janeiro de 2038.
Correções de curto prazo podem envolver a aplicação de patches no software para lidar corretamente com valores de tempo negativos. Mas isso é um curativo. A solução permanente requer a atualização para um formato de hora de 64 bits.
A questão não é se o código será quebrado. É se os sistemas que executam esse código serão atualizados antes que o tempo acabe.
A maior parte da infraestrutura da qual dependemos já está migrando para a cronometragem de 64 bits. Mas nem tudo é. Servidores antigos. Equipamento industrial legado. Alguma lógica incorporada. Esses são os elos fracos.
Quando chegar 19 de janeiro de 2038, o relógio atingirá seu limite. Para alguns sistemas, não será um evento. Para outros, será uma parada difícil. Não haverá muito tempo para corrigir o código se você esperar até o último minuto.
