Em 2000, o bug Y2K veio e foi sem muitos problemas. Apesar das previsões de falha generalizada, a crise foi evitada tanto pelo planeamento e intervenção a longo prazo como de última hora, e nenhum sistema crítico falhou. Nos anos seguintes, aqueles poucos sistemas operacionais e aplicações que foram afetados foram, na maioria dos casos, atualizados, substituídos ou aposentados.
Se você usar um sistema baseado em Unix ou Linux, há mais um bug relacionado à data com o qual você precisará se preocupar — no ano 2038.
Todos os sistemas baseados em Unix/Linux de 32 bits armazenam o tempo do relógio do sistema internamente como o número de segundos desde a época, ou 00:00:00 em 1 de janeiro de 1970. Este tipo de dado interno, time_t, é na maioria dos casos um inteiro de 32 bits (4 bytes) assinado. Se o sistema em questão segue o padrão POSIX (como a maioria dos sistemas Unix e Linux), a última hora e data que pode ser representada como segundos – desde o Epoch naquele inteiro assinado de 32 bits é 3:14:07 UTC na terça-feira, 19 de janeiro de 2038.
Após esta hora e data, a representação interna da hora do sistema chegará a 2147483647, o número mais alto armazenável em um inteiro assinado de 32 bits. Um segundo depois disso, ele se envolverá em um número negativo, -2147483648. As aplicações actuais irão interpretar este número negativo como um ano mais antigo (1901) ou congelar o relógio do sistema às 03:14:07 do dia 1/19/2038. Isto possivelmente fará com que aplicações e sistemas operacionais falhem, já que não foram projetados para funcionar com um relógio de sistema suspenso ou um que mostra o ano como 1901.
Não há correções viáveis (que não quebram aplicações existentes) para sistemas que utilizam processadores de 32 bits, ou sistemas operacionais e aplicações rodando em modo 32-bit em processadores de 64-bit. Muitos sistemas operacionais Unix/Linux atuais já rodam em modo 64-bit (com um time_t “longo” correspondente quando em um processador de 64-bit; na maioria dos casos isso resolve o problema.
Sistemas operacionais que suportam um time_t longo de 64-bit não são muito provavelmente afetados pelo bug do Ano 2038 em termos do relógio interno do sistema. No entanto, aplicações que usam um time_t de 32 bits ainda podem falhar, mesmo que o sistema rodando a aplicação suporte operação completa de 64 bits.
Aqui está uma rápida visão geral do status atual do suporte ao Unix 2038 nas principais versões Unix/Linux:
- Solaris 7 ou superior nos processadores UltraSPARC e SPARC64 de 64 bits, assim como Solaris 10 nas plataformas x86-64, tem um time_t de 64 bits.
- Versão AIX 4.3.3 em processadores PowerPC de 64 bits e Power tem um time_t de 64 bits.
- O kernel Linux a correr em modo 64-bit em processadores IA64 ou x86-64 tem um time_t de 64-bit.
- Mac OS X Versão 10.4 e mais recente tem um kernel de 32 bits, mas aplicativos podem usar um time_t de 64 bits quando em execução no PowerPC G5 ou x86-64 CPUs.
- FreeBSD 6.0 e superior tem um time_t de 64 bits quando em execução em uma plataforma de 64 bits.
- OpenBSD 4.1 e mais recentes suportam um time_t de 64 bits.
- ANetBSD ainda não tem um time_t de 64 bits, mas esforços estão em andamento para corrigir o problema para uma próxima versão.
Even se o seu sistema operacional atual ainda não é seguro para o Unix 2038, não se preocupe! As pessoas estão conscientes do problema há muitos anos, e estão trabalhando ativamente em soluções. Na maioria dos casos, o problema será resolvido tendo o sistema operacional e as aplicações eventualmente rodando em modo full 64-bit.
Eu espero que todos os principais sistemas operacionais desktop sejam totalmente 64-bit nos próximos cinco a 10 anos. Além disso, um efeito de trickle down ajudará a substituir os sistemas atuais com configurações de 64 bits onde for aplicável e rentável.
ABOUT THE AUTHOR: Bill Bradford é o criador e mantenedor da SunHELP e vive em Houston, Texas, com sua esposa Amy.