A nova preocupação: o bug do ano 2038

Flavia Dutra · 8 de maio de 2023

Tópico para a discussão do seguinte conteúdo publicado no Clube do Hardware:

"Conheça o bug do ano 2038, que causa alguns programas de computador a mostrarem a data incorreta a partir daquele ano."

Comentários são bem-vindos.

Atenciosamente,
Equipe Clube do Hardware
https://www.clubedohardware.com.br

gavihawk · 9 de maio de 2023

Amém que nos possuímos IAs muitos espertas pra resolver problemas como este

Gabriel Torres · 11 de maio de 2023

Em 09/05/2023 às 12:30, die4peace disse:

Amém que nos possuímos IAs muitos espertas pra resolver problemas como este

IA não resolve esse tipo de problema. É como dizer que IA vai resolver problema de motor de carro. Alguém tem que ir lá abrir o motor e consertá-lo.

gavihawk · 12 de maio de 2023

@Gabriel Torres sim, de certa forma está certo mas da mesma forma que alguém vai ter que ir lá consertar o carro, ele irá usar alguma ferramenta.. existe ferramentes que deixa essa ajuda quase automatizada.
Para desparafuzar uma roda de carro, hoje usam aquelas maquina encaixou apertou rodou automatico e pronto... Em pensar que antigamente fazer aquilo demorava muito mais do que hoje em dia..
Da mesma forma que uma IA pode ser e creio eu que vai ser uma ferramenta muito bem usada na questão do noticia acima.

Marcos FRM · 15 de maio de 2023

Falando do Linux...

Lembrando que isso afeta apenas arquiteturas 32-bit em que time_t seja 32-bit (a maioria). O grosso da solução é substituir time_t 32-bit por 64-bit. Requer no mínimo uma recompilação dos programas -- e possivelmente mudanças no código.

No kernel, está encaminhado desde, mais ou menos, o 5.6 (https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=22b17db4ea05561c7c8e4d770f10751e22e339f9). Faz anos que Arnd Bergmann enfrenta o problema. Os principais sistemas de arquivos também suportam datas posteriores (Btrfs, XFS, EXT4, ...). No espaço de usuário, a glibc, biblioteca C mais popular, manterá as interfaces antigas para programas que não possam ser recompilados/adaptados:

https://sourceware.org/glibc/wiki/Y2038ProofnessDesign

Podemos esperar que todos os componentes críticos sejam portados muito antes da fatídica data.

No entanto, mesmo em arquiteturas 64-bit, há alguns lugares em que time_t continua sendo 32-bit:

https://github.com/thkukuk/utmpx/blob/main/Y2038.md

O pessoal da glibc simplesmente não vai consertar essas interfaces, pois são consideras obsoletas. Então, Thorsten Kukuk da SUSE tem trabalhado em substitutos.

Não vai ser uma hecatombe, pois:

1) Arquiteturas 64-bit serão a esmagadora maioria em 2038 e os poucos pontos de fraqueza (como as interfaces citadas acima) terão sido resolvidos.
2) Arquiteturas 32-bit requererão mais trabalho. Os códigos importantes estarão preparados. Algum programa caduco que outro não será atualizado e vai ter problema em 2038.