Depois do Bug do milênio, vem agora o BUG de 2038
O bug de 2038 é um problema de programação relacionado ao sistema de tempo de computadores que utilizam a estrutura de dados de 32 bits para armazenar informações sobre a data e hora. Essa estrutura de dados utiliza 32 bits para representar o número de segundos desde 1 de janeiro de 1970, o chamado “epoch” ou início do tempo Unix. Como os bits só podem armazenar números positivos até o valor de 2^31-1, o contador de segundos atingirá o valor máximo em 19 de janeiro de 2038, e a partir daí, começará a contar a partir do valor inicial novamente, causando problemas para os sistemas de computação que utilizam essa estrutura de dados.
Isso significa que os sistemas de computação que utilizam a estrutura de dados de 32 bits para armazenar informações sobre a data e hora podem apresentar problemas como falhas, erros e crashes, ao lidar com datas futuras após 2038. Para evitar esses problemas, é necessário implementar soluções, como a utilização de estruturas de dados de 64 bits para armazenar informações sobre a data e hora, ou a utilização de sistemas operacionais e aplicativos que já estejam preparados para lidar com essa limitação.
Saia do yahoo messenger ou do gmail talk. Abra as configurações de data e hora do sistema. Altere o ano para qualquer coisa além de 2038. Você pode tentar definir o ano para 2040. Agora tente fazer login em qualquer um dos mensageiros. Não loga e dá algum erro. Surpreso?
Se você usa Windows, abra o Explorador do Windows Explorer e em C:\ repare que há 2 estruturas de Arquivos de programas, pastas onde são instalados a maioria dos programas que rodam em seu computador.
Há duas estruturas: C:\Arquivos de Programas e C:\Arquivos de Programas (x86).
Todos os programas que estão na primeira pasta, são aplicações 64 bits, já os que estão na pasta com final x86, as aplicações em 32bits.
O Linux na sua versão 5.1 já tem a correção no seu sistema operacional. Como estamos em meados de 2023, raramente encontraremos um processador 32bits e se há algum rodando, está com os dias contados!
A origem do problema é, na verdade, a maneira como alguns (principais) aplicativos armazenam seus tipos de dados de data/hora. Os programas que usam representação de tempo POSIX serão afetados por esse problema. A estrutura time_t é um tipo de valor que armazena tempo em um inteiro com sinal de 32 bits. Ele armazena o tempo como número de segundos decorridos desde 1º de janeiro de 1970. Portanto, é capaz de representar o tempo que pode ser endereçado em um total de 231 segundos. De acordo com isso, o último horário que ele pode armazenar é 03:14:07 UTC, terça-feira, 19 de janeiro de 2038. Após esse horário, o bit de sinal do inteiro assinado de 32 bits será definido e representará um número negativo . Como eu disse, o tempo é armazenado como número de segundos decorridos desde 1º de janeiro de 1970, esse número negativo será adicionado para calcular o tempo de acordo com os padrões POSIX. Mas, sendo um número negativo, ele calculará o tempo subtraindo esses segundos de 1º de janeiro de 1970, o que acabará gerando uma data-hora histórica que fará com que os aplicativos falhem. Esta hora será sexta-feira, dezembro de 1901 e é chamada de data final. Aplicações escritas em linguagem C, COBOL e muitos sistemas operacionais também serão afetadas, pois a apresentação de tempo POSIX é amplamente utilizada lá. A animação abaixo visualiza o cenário real de uma maneira mais fácil. Esse bug geralmente é indicado como bug “Y2038″, “Y2K38” ou “Y2.038K”.
Redator: Norberto Gomes
Fontes: https://www.codeproject.com/
