Do Bug do Milênio ao Problema de 2038: Quando o Calendário Vira Ameaça para os Computadores
Na virada para 2000, o mundo gastou bilhões para impedir que computadores achassem que tinham voltado a 1900. Em 19 de janeiro de 2038, um limite parecido reaparece. Entenda por que datas são tão traiçoeiras para os computadores.
Do Bug do Milênio ao Problema de 2038: Quando o Calendário Vira Ameaça para os Computadores
Na virada de 1999 para 2000, muita gente estocou água, sacou dinheiro do banco e passou a meia-noite com medo de que aviões caíssem, usinas parassem e o sistema financeiro entrasse em colapso. O motivo era um detalhe de programação aparentemente bobo: dois dígitos.
O episódio ficou conhecido como bug do milênio, ou Y2K (de "Year 2000"). E ele tem um primo mais novo, com data marcada: 19 de janeiro de 2038.
Por que os programadores escreviam o ano com dois dígitos
Nos anos 1960 e 1970, memória de computador era caríssima. Cada caractere guardado custava dinheiro, espaço em fita magnética e tempo de processamento. Então, para economizar, muitos sistemas guardavam o ano com apenas dois dígitos: 1975 virava "75".
Funcionava perfeitamente, desde que o século não mudasse. Os programadores da época sabiam do limite, mas imaginavam que aqueles sistemas seriam substituídos muito antes do ano 2000. Não foram. Programas escritos em COBOL nos anos 1970 continuavam rodando em bancos, governos e companhias aéreas no fim dos anos 1990.
O que poderia dar errado
Quando o relógio passasse de "99" para "00", um sistema desses poderia entender que o ano era 1900. Contas simples virariam absurdos:
- Um cliente nascido em "80" teria, em "00", menos 80 anos de idade.
- Juros calculados entre "99" e "00" poderiam sair negativos ou gigantescos.
- Um registro feito em "00" apareceria como mais antigo que um de "99", bagunçando ordenações e prazos.
O bug que não aconteceu (porque deu muito trabalho)
A meia-noite de 1º de janeiro de 2000 passou quase sem incidentes graves. Por isso, até hoje muita gente acha que o bug do milênio foi exagero.
Foi o contrário. Durante anos, empresas e governos do mundo inteiro revisaram milhões de linhas de código, testaram sistemas simulando a virada e corrigiram o que encontraram. As estimativas do custo total chegam à casa das centenas de bilhões de dólares. Houve falhas pontuais, mas o colapso não veio justamente porque o problema foi levado a sério.
Esse fenômeno tem nome: paradoxo da prevenção. Quando a prevenção funciona, o desastre não acontece, e então parece que nunca houve risco. Vale para software, para vacinas e para a manutenção de pontes.
2038: o relógio do Unix
Muitos sistemas, especialmente os derivados do Unix, como o Linux, que roda na maioria dos servidores da internet e por baixo do Android, não guardam a data como dia, mês e ano. Eles contam segundos a partir de um momento fixo: a meia-noite de 1º de janeiro de 1970, no horário UTC. Esse ponto de partida é chamado de "época Unix".
Contar segundos é elegante: para saber quanto tempo passou entre dois eventos, basta subtrair. O problema está em onde esse número é guardado.
Em muitos sistemas antigos, o contador ocupa 32 bits com sinal. O maior número que cabe ali é 2.147.483.647. Somando essa quantidade de segundos a 1º de janeiro de 1970, chega-se a:
19 de janeiro de 2038, às 03h14min07s (UTC).
Um segundo depois, o contador "transborda" e salta para o menor valor possível, que é negativo. Para o sistema, a data passa a ser 13 de dezembro de 1901. É o mesmo tipo de defeito do bug do milênio, só que em binário.
Já está resolvido?
Em grande parte, sim. Sistemas modernos de 64 bits usam um contador de tempo de 64 bits, que só vai transbordar daqui a cerca de 292 bilhões de anos, muito depois de o Sol ter se apagado. O Linux também recebeu correções, por volta de 2020, para que até sistemas de 32 bits possam usar datas de 64 bits.
O risco mora em outro lugar: nos sistemas embarcados, os computadores pequenos escondidos dentro de equipamentos industriais, carros, roteadores, catracas e aparelhos médicos. Muitos rodam por décadas sem atualização. E arquivos e bancos de dados que guardam datas em 32 bits também precisam ser revistos, mesmo em máquinas modernas.
E 2038 não está tão longe quanto parece: um sistema que calcula um financiamento de 15 anos já precisa lidar hoje com datas depois de 2038.
O GPS também tem o seu "bug do milênio"
Datas são tão traiçoeiras que até o GPS tem um caso parecido. Os satélites informam a data contando semanas, num campo que só vai até 1.023. Quando chega ao fim, o contador volta a zero, o que acontece a cada cerca de 19,7 anos.
A virada mais recente foi em abril de 2019. Receptores que não estavam preparados passaram a mostrar datas quase 20 anos no passado, e alguns sistemas que dependiam do horário do GPS apresentaram falhas. Aliás, como o GPS funciona é uma história fascinante por si só, que envolve até a relatividade de Einstein.
A lição para quem programa
O bug do milênio e o problema de 2038 ensinam algo que vale para qualquer código:
- Todo limite um dia é alcançado. Se o seu programa guarda um número numa variável com tamanho máximo, pergunte o que acontece quando esse máximo chegar.
- Código dura mais do que se imagina. Os programadores dos anos 1970 não esperavam que seus sistemas chegassem ao ano 2000. Muitos chegaram.
- Datas são difíceis. Fusos horários, anos bissextos, horário de verão e segundos intercalares já derrubaram muitos sistemas. Use bibliotecas testadas em vez de reinventar o calendário.
Histórias como esta, a da mariposa presa no Harvard Mark II e a do computador da Apollo 11 mostram que entender como o computador pensa é a melhor defesa contra os erros dele. Para começar do básico, o curso gratuito de Lógica de Programação do zero explica variáveis, limites e condições passo a passo.