Bug do ano 2038 e segundo bissexto

Pra começar o post, vi uma tirinha do LibMan e APIBoy, com uma pequena referência ao bug do ano 2038. Bug do ano 2038?! Isso que eu chamaria de evolução no planejamento de software. Eu ainda não consigo nem saber que features vão ser implementadas no TAF no próximo ano, e já tem gente sabendo que bugs vão existir em 2038! Bom, parando com a brincadeira. Quem não conhecia e ainda não seguiu o link para o segundo guru da internet (wikipedia), o bug do ano 2038 é basicamente um problema para quem usa representação de datas estilo POSIX (e quem não usa???), onde a data é representada pelo número de segundos passados desde o início da era, no caso, 1-Jan-1970. O problema é que esse valor é representado por um inteiro sinalizado de 32 bits. Mas por que usar uma representação de datas usando inteiros de 32 bits e com sinal? Primeiro, lá em 1985, mais ou menos quando o POSIX foi lançado, acho que parecia bastante lógico que 2147483647 de segundos no futuro nenhum daqueles computadores estariam em uso, então, pra que se preocupar? Afinal, no ano 2000 já teríamos carros voadores, computadores com uma inteligência praticamente humana, no melhor estilo HAL, ponte aérea (??) entre a Terra e Marte, etc, não havia a menor chance de ainda usarmos os obseletos computadores de 32 bits - que ainda nem existiam. Mas tudo bem, podiam ter pelo menos colocado um unsigned na frente do time_t, né? Não exatamente. E como ficariam as datas antes de 1970? Certo, a decisão de usar signed int parece bem razoável. Então, assim como em 2000, os sistemas que usam datas vão entrar em colapso, certo? Bom, mais ou menos. É possível que se nada for feito, o segundo seguinte a data 03:14:07 de 19-Jan-2038 será 13-Dez-1901, 20:45:42. Ei, mas já estamos colocando processadores 64 bits agora, até 2038 ninguém mais vai usar 32 bits, certo? Eu espero que sim, mas existem algumas indicações contrárias. Já com o negócio do bug do ano 2000, vários sistemas extremamente legados, ainda em Cobol e fortran, ainda estavam em utilização, e recodificar alguns bugs pode não ser uma opção adotada por algumas empresas, para reduzir o custo. Além disso, temos os vários sistemas embutidos (ou embarcados - esse último parece ser o termo mais utilizado, mas tem algo nele que eu não gosto. Pessoal da área de embedded systems, qual o certo?) que provavelmente não usam 64 bits, e muito provavelmente vão continuar em operação até além de 2038. Só espero que os sistemas que controlam aviões, satélites, e outras coisas grandes que correm um risco de cair nas nossas cabeças não sofram nenhum efeito colateral sério por causa desse bug, assim como sistemas de monitoração de usinas nucleares e outras coisas que possam fazer um "grande boom". E também, mudar para 64 bits não resolve o problema, só posterga para 4 de dezembro de 292.277.026.596 as 15:30:08, mas aí acho que podemos deixar para as futuras gerações resolverem, ou postergarem ainda mais usando 128 bits ;).

Bom, e o que isso tudo tem relacionado com segundos bissextos? Nada, na verdade, exceto que a contagem de segundos na data POSIX não leva em consideração os segundos bissextos. Eu só achei um termo novo e resolvi comentar :D. Já é de conhecimento natural que a cada 4 anos temos um ano bissexto, que inclui um dia extra em Fevereiro. Essa acho que é uma das maiores gambiarras da humanidade. Ao invés de fracionar as unidades de tempo de forma a todo ano ficar bem alinhado, a preguiça imperou e inventaram esse negócio de incluir um dia a mais em alguns anos para "limpar" a imprecisão. Bom, é da natureza humana ir pelo lado mais fácil, por isso, eu simplesmente critiquei a solução e nem procurei saber se existe alguma forma de fazer um fracionamento exato ;). Mas parece que mesmo a divisão do dia em 86400 segundos não é lá muito preciso. Na verdade, dessa vez a culpa é da própria Terra. A cada século, o dia solar (que não respeita nossos relógios) fica 1,7 milissegundos maior, ou seja, daqui a 6 séculos, nossos dias terão 1 segundo a mais. Mas, a nossa divisão de datas continua 1 dia * 24 horas * 60 minutos * 60 segundos, sem espaço para esse segundo adicional, então fizeram esse negócio de segundo bissexto. Em alguns anos específicos é inserido 1 segundo a mais, sincronizado mundialmente. Normalmente, esse segundo adicional é colocado no dia 30-Junho ou 31-Dezembro. No caso, quando o relógio em UTC chegar a 31-Dez, 23:59:59, ao invés de mudar para 01-Jan, 0:00:00, ele primeiro vai para 31-Dez, 23:59:60, e depois para 0:00:00. Esse ajuste é feito simultaneamente em todo o mundo, por um sistema de difusão, ou seja, aqui no Brasil o ajuste é feito as 21:59:59, considerando o horário de verão. Agora eu me pergunto, será que meu relógio de pulso se ajusta automaticamente em relação a segundos bissextos? Se não, acho que descobri porque em 2005 ele estava errado em 1 segundo.

Só pra constar, os últimos 10 anos que sofreram ajuste de segundo bissexto foram: 2005, 1998, 1997, 1995, 1994, 1993, 1992, 1990, 1989, 1987.