A maioria das pessoas ouviu falar algo sobre o conhecido bug do ano 2000, principalmente em virtude da grande atenção que recebeu dos meios de comunicação.
A maior parte dos programas escritos na linguagem de programação em C é relativamente imune ao bug do ano 2000, mas sofre, em vez disso, com o bug do ano de 2038. Este problema surge porque a maioria dos aplicativos em C usa uma biblioteca de rotinas chamada de biblioteca de tempo padrão. Esta biblioteca estabelece um formato padrão de 4 bytes para o armazenamento de valores de tempo, e também oferece diversas funções para a conversão, exibição e cálculo de valores de tempo.
O formato padrão de 4 bytes presume que o começo do tempo é 1 de janeiro de 1970, às 12h00 min. Este valor é 0. Qualquer valor de tempo/data é expresso como o número de segundos após esse valor de zero. Portanto, o valor 919642718 é 919.642.718 segundos passados das 12h00m00s de 1 de janeiro de 1970, que é domingo, 21 de fevereiro de 1999, às 16h18m38s (hora do Pacífico) (EUA). Este é um formato conveniente, porque se subtraímos quaisquer dois valores, o resultado é um número de segundos, que é a diferença de tempo entre ambos. Depois, você pode usar outras funções na biblioteca para determinar quantos minutos/horas/dias/meses/anos se passaram entre os dois momentos.
Se você leu nosso artigo sobre os bits e os bytes, já sabe que um inteiro de 4 bytes com sinal tem um valor máximo de 2.147.483.647, e é daí que vem o problema ou bug do ano 2038. O valor máximo de tempo antes dele rolar para um valor negativo (e inválido) é 2.147.483.647, que se traduz em 19 de janeiro de 2038. Nesta data, quaisquer aplicativos em C que usem a biblioteca de tempo padrão começarão a ter problemas com o cálculo da data.
Felizmente, este bug é um pouco mais fácil de consertar que o bug do ano 2000 em mainframes. Programas bem escritos podem simplesmente ser compilados com uma nova versão da biblioteca que usa, por exemplo, valores de 8 bytes para o formato de armazenamento. Isso é possível porque a biblioteca encapsula a atividade de todo o tempo com seus próprios tipos e funções de tempo (diferentemente da maioria dos programas para mainframe, que não padronizaram seus formatos ou cálculos de datas). Portanto, o problema do ano 2038 não será nem de longe tão difícil de consertar quanto foi o problema com o ano 2000.
Um leitor alerta teve a gentileza de nos informar que os PCs da IBM sofrem do problema do ano 2116. Para um PC, o começo do tempo é 1 de janeiro de 1980, e apresenta incrementos de segundos em um inteiro de 32 bits sem sinal de um modo semelhante ao tempo em UNIX. Em 2116, o inteiro esgota-se.
O Windows NT usa um inteiro de 64 bits para marcar o tempo. Entretanto, ele usa 100 nanossegundos como seu incremento e o começo do tempo é 1 de janeiro de 1601, de modo que o NT sofrem do problema do ano de 2184.
Nesta página (em inglês), a Apple declara que o Mac não apresentará tais problemas até o ano de 29.940!