sábado, 19 de janeiro de 2008

Bug do Ano 2000 ... em 2038 ...

Bom pessoal, não quero alarmar ninguém mas, estamos nos aproximando novamente de um ponto onde as datas irão quebrar, como havia sido previsto para acontecer no ano 2000. Foi frustrante, mas na véspera, todos esperaram os blecautes, equipamentos parando de funcionar, sistemas russos ativando medidas defensivas com silos de mísseis ICBM nucleares, EUA ativando a diretiva DEFCON 1, o mundo entrando em uma terceira guerra mundial, tudo por que um campo de data usava 32 bits de dados. Agora, estamos próximos novamente da iminente data, que agora está para acontecer em 03:14:08 do dia 19 de janeiro de 2038.

O problema do ano 2038 é uma falha na representação de datas em computadores, que pode causar erros em alguns programas de computador no ano de 2038...


O problema afeta os programas que utilizam a representação de tempo POSIX, em que a data é calculada através do número de segundos (ignorando os segundos bissextos) desde 1 de janeiro de 1970. Esta representação é padrão nos sistemas operacionais do tipo Unix e afeta a maioria dos sistemas, pois grande parte deste software foi desenvolvido na linguagem C. Na maioria dos sistemas de 32 bits, o tipo de dados time t, utilizado para armazenar esta contagem de segundos, é um inteiro de 32 bits do tipo signed (considera o sinal). O último registro de tempo que pode ser representado por este formato, seguindo o padrão POSIX, é 03:14:07 na terça-feira 19 de janeiro de 2038 (UTC). Após este momento a data será representada por um número decimal negativo que, dependendo da implementação, corresponderá ao ano 1970 ou 1901. Este valor para a data corrente certamente resultará em erros de cálculo e de funcionamento na maior parte dos programas em execução pelo sistema.

Solução

Não há maneira simples de resolver este problema para os sistemas existentes. Alterar a definição do time_t para 64 bits pode quebrar a compatibilidade binária de softwares, dados persistidos e de qualquer sistema que manipule datas representadas no formato binário. Alterar o time_t para um inteiro de 32 bits unsigned (não considera o sinal) pode alterar vários programas que trabalham com diferenças de tempo.

A maioria dos sistemas que suportam a arquitetura de 64 bits já suportam o time_t de 64 bits. A migração para esta arquitetura já está em andamento e muitos esperam que ela esteja completa até 2038. Porém, milhões de sistemas de 32 bits foram instalados até o ano de 2006, muitos em sistemas embarcados, e é muito incerto se eles serão totalmente substituídos até 2038. Apesar de, normalmente, os sistemas serem atualizados num prazo de 18-24 meses, os sistemas embarcados podem operar sem alterações por toda a vida do sistema que controlam. A utilização do time_t de 32 bits foi codificada em alguns formatos de arquivo, como o ZIP, o que significa que o problema pode permanecer por um longo período após a expiração da vida útil das máquinas envolvidas.

A utilização de valores de 64 bits introduz um novo "corte" na data em aproximadamente 290 bilhões de anos, num domingo em 4 de dezembro de 292.277.026.596 as 15:30:08 (UTC). Claramente este problema não é uma questão imediata.

Se você quizer verificar se seu sistema vai dar esse problema (e provavelmente dará), existe uma forma interessante de testar. O código a seguir recupera o tempo corrente, o formata como uma cadeia de caracteres e o escreve na saída padrão:
#include <stdio.h>
#include <time.h>

int main(void){
time_t now;
struct tm ts;
char buf[80];

// Obtem o tempo corrente
time(&now);

// Formata e imprime o tempo, "ddd dd-mm-YYYY hh:mm:ss zzz"
ts = *localtime(&now);
strftime(buf, sizeof(buf), "%a %d-%m-%Y %H:%M:%S %Z", &ts);
printf("%s\n", buf);

return 0;
}

Para repetir em sistemas linux, use o comando a seguir, que muda a data do sistema para um ponto no futuro, 1 minuto antes do derradeiro acontecimento. Só um aviso: Não me responsabilizo por problemas que isso possa causar em seu sistema. Se você é corajoso o suficiente, assuma o risco por você mesmo. Eu testei e funcionou, depois voltei para a data corrente e o sistema deu umas travadas e precisou ser formatado sobreviveu sem nenhum problema. Boa sorte. O comando pra mudar a data é:
date 011903132038.08
( sintaxe do comando: date [MMDDhhmm[[CC]YY][.ss]] )

E aqui, para aqueles que tem medo, uma imagem que mostra o que acontecerá com a data e a hora:



O que acontece com os sistemas, no entanto, somente os deuses podem dizer. Que eles tenham piedade de nós hehehehee

Flws povo !!

Referências:
http://www.2038bug.com
http://www.2038bug.com/64-bit.html
http://en.wikipedia.org/wiki/DEFCON
http://en.wikipedia.org/wiki/Year_2038_problem