O Linux Kernel 4.18 já está em pleno desenvolvimento, e a equipe do Linus já está envolvido para resolver o problema que pode bater a porta assim que o ano de 2038 chegar. Para quem acha que é algo do passado acertou. Na verdade a mesma situação aconteceu nos anos 90, quando nós virássemos o ano de 1999 para o ano 2000, e por isso que ficou conhecido como bug do milênio.
O receio do mundo de TI na época, era que ao virar para o 2000 as datas dos sistemas ao redor do mundo, especialmente os desenvolvidos em COBOL e similares retornassem suas datas para o ano de 1900, os principais prejuízos seriam aos correntistas de bancos que ficariam com status de devedores com boletos vencidos a pelo menos 100 anos, e assim imagine 100 anos de juros, pois é, e agora, mais pessoas suscitaram que o problema pode ocorrer novamente em 2038, e pensando nisso o desenvolvimento do Linux Kernel 4.18 já está fazendo testes para evitar que a situação temerosa ocorra.
Na época o ano 2000 chegou e nada ocorreu, mas teve gente que ficou imaginando aviões caindo e até misseis sendo disparados no mundo inteiro devido a essa possível pane. O bug do milênio só que desta vez de 2038 já tem data para ocorrer, seria em 19 de janeiro do mesmo ano. O erro pode ocorrer em sistemas desenvolvidos em C, em resumo, seriam aqueles sistemas cuja data é calculada pelo número de segundos desde o dia 1 de janeiro de 1970, ao meio dia.
Por usar um formato padrão de 4 bytes, o número máximo positivo que estes sistemas conseguem chegar é 2.147.483.64 (03:14:07 pelo código UTC – Coordinate Universal Time), ou seja, a data de 19 de janeiro de 2038. E depois disso, os números iriam passar a contar de forma negativa. Voltaríamos para o dia negativo 13 de dezembro de 1901 que olhando no calendário cairia numa sexta-feita 13, estranho em.
Para resolver este probleminha, basta que ao invés de 4 bytes os sistemas sejam programados para 8 bytes para armazenar as datas, basicamente é mudar a datação de 32 bits para 64 bits, isso garantiria 292 bilhões de anos no futuro.
Mas, usar uma datação de 64 bits em sistemas de 32 bits pode dar um problema danado, por isso, ainda há a ideia de que daqui para o ano de 2038, os sistemas já devem ser todos de 64 bits e o 32 bits deve ser aposentado em breve.
Se você precisa de mais informações sobre o desenvolvimento do Linux Kernel 4.18 e sobre o status da correção do erro do ano de 2038, você pode consultar o botão abaixo e acompanhar toda a tramitação sobre o assunto.