Os trens da RATP estão expostos à falha do ano de 2038, um problema de compatibilidade que pode afetar sistemas que dependem de uma contagem limitada de tempo. O tribunal administrativo de Paris condenou a Alstom a corrigir essa irregularidade.
Depois da preocupação provocada pelo bug do ano 2000, voltou a surgir o receio de uma nova quebra de calendário: a falha de 2038. Trata-se de um defeito ligado à forma como certas datas são registradas em sistemas computacionais e que não afeta apenas computadores. No caso francês, ele também alcança parte da frota ferroviária.
Como a falha de 2038 foi identificada nos trens da RATP
Segundo o jornal francês Le Parisien, que cita uma reportagem de L’Informé, a exposição da RATP a esse problema teria sido descoberta por acaso em 2017. Na ocasião, funcionários tentaram inserir no software de um trem MI09 uma data posterior a 2037. O teste revelou a limitação do sistema.
A situação, no entanto, não parecia ser pontual. De acordo com a reportagem citada, pelo menos 38 trens estariam envolvidos. O impacto também seria amplo no conjunto da rede operada pela RATP, alcançando mais de um terço do sistema, incluindo o RER A e oito linhas de metrô.
A RATP teria solicitado à Alstom que estudasse o caso já em 2018. Como não houve resposta prática satisfatória, a operadora levou a questão à Justiça em 2019. Agora, segundo L’Informé, o tribunal administrativo de Paris determinou, em 13 de novembro, que a Alstom corrija a falha. A empresa recebeu prazo de cinco anos para resolver o problema, após a elaboração de um diagnóstico que deverá ser concluído em até 12 meses. Citada por Le Parisien, a Alstom afirmou ter “tomado conhecimento da decisão do tribunal administrativo de Paris” e informou que vai recorrer.
Falha do ano de 2038: por que esse problema acontece?
A falha de 2038 pode gerar consequências relevantes no mundo todo caso continue sem solução nos sistemas afetados. O motivo está na maneira como o tempo é armazenado em alguns programas: o código conta os segundos transcorridos desde 1º de janeiro de 1970, início do chamado “tempo Unix”.
Para visualizar isso, basta observar que o instante em que este texto é escrito corresponde ao tempo Unix 1765452748, isto é, 1.765.452.748 segundos passados desde 1º de janeiro de 1970. O ponto crítico aparece em softwares desenvolvidos em 32 bits, nos quais esse contador atinge seu limite máximo em 19 de janeiro de 2038, às 3h14min07s, no tempo universal. Nesse instante, o valor chega a 2.147.483.647.
Em termos práticos, quando esse teto é alcançado, sistemas antigos podem interpretar a data de forma errada, exibindo horários incorretos ou até recusando comandos que dependem do calendário. Por isso, o problema preocupa especialmente equipamentos de longa vida útil, como sistemas ferroviários, que costumam permanecer em operação por décadas e nem sempre recebem atualizações de software no mesmo ritmo de um computador pessoal.
O que a Alstom alegou no processo
De acordo com Le Parisien, a Alstom sustentou diante do tribunal que esse prazo já vinha sendo mencionado em publicações desde 1999. A empresa também afirmou que foi a própria RATP quem teria recomendado o uso de softwares de código aberto, geralmente desenvolvidos em 32 bits. Ainda assim, a decisão judicial teria considerado que a RATP, responsável apenas pelos transportes de Paris e da região de Île-de-France, não possui competências técnicas equivalentes às da Alstom Transport, empresa que fabrica e projeta material rodante.
O caso chama atenção porque evidencia um desafio cada vez mais frequente em infraestrutura pública: sistemas criados para durar muito tempo precisam ser acompanhados por manutenção contínua, auditorias de segurança e migrações tecnológicas planejadas. Quando essa atualização não ocorre no ritmo necessário, falhas aparentemente distantes no calendário podem se transformar em risco operacional real.
A discussão também reforça a importância de revisar equipamentos críticos antes de marcos conhecidos no setor de tecnologia. Em redes de transporte, qualquer erro de data pode afetar testes, sinalização, rotinas de bordo e procedimentos de manutenção. Por isso, a correção antecipada costuma ser muito menos custosa do que enfrentar uma interrupção quando o limite finalmente chega.
Comentários
Ainda não há comentários. Seja o primeiro!
Deixar um comentário