Debian muda para um sistema de tempo totalmente em 64 bits sem esperar pelo problema de 2038

• O Debian oficializou a adoção de time_t de 64 bits até mesmo para arquiteturas de 32 bits a partir da próxima versão, Debian 13, para bloquear preventivamente o problema Y2K38 (Unix Epochalypse)
• Devido à limitação do time_t atual de 32 bits, pode ocorrer um fenômeno em que o tempo volte para 1900 após 19 de janeiro de 2038, e a decisão foi não deixar mais esse problema sem tratamento
• Embora o hardware de 64 bits já esteja seguro, foi enfatizada a necessidade de agir com antecedência porque ainda existe demanda por Debian em dispositivos de 32 bits sensíveis a custo, como embarcados e IoT
• Está em andamento um trabalho de grande escala para migrar simultaneamente o tipo time_t, distribuído por 6.429 pacotes, aceitando de uma vez a quebra de compatibilidade ABI
• Algumas arquiteturas legadas com suporte, como i386 e hurd-i386, permanecem como exceção, mas também foi mencionada a possibilidade de introduzir uma nova arquitetura x86 (i686) baseada em time_t de 64 bits

---

Resposta do Debian ao bug Y2K38: transição para tempo em 64 bits

• O Debian está mudando para tempo em 64 bits em todos os ambientes, exceto em parte do hardware mais antigo ainda suportado, para evitar o problema iminente Y2K38, ou Unix Epochalypse
• Com isso, previne o erro em valores de tempo causado pelo estouro do intervalo de signed int de 32 bits, previsto para 19 de janeiro de 2038

Contexto do problema Y2K38 e Unix Epochalypse

• O problema Y2K38 ocorre em sistemas Unix que representam os segundos transcorridos desde 1º de janeiro de 1970 com um signed int de 32 bits; após 2038, acontece um overflow e o relógio pode voltar incorretamente para datas passadas, como 1900
• Assim como o antigo Y2K (bug do ano 2000), isso decorre de uma decisão arquitetural de escolher um formato de dados curto
• Na época do Y2K, foi possível evitar um grande caos graças à ação preventiva dos desenvolvedores
• Softwares para hardware de 64 bits já estão seguros, mas o Debian ainda é amplamente usado em ambientes embarcados, de baixo desempenho e legados

Principais medidas do Debian

• A partir do lançamento do Debian 13 "Trixie", o time_t de 64 bits passa a ser o padrão em todas as principais arquiteturas
• O hardware de 64 bits já está protegido, mas o problema é frequente em dispositivos embarcados baseados em processadores de 32 bits e hardware legado
• Esses equipamentos ainda são usados em áreas sensíveis a custo e de grande volume de envio, como controle automotivo, IoT, TVs e roteadores
• Muitos equipamentos novos usam Linux compilado sob medida, como OpenEmbedded, Alpine, Android e Gentoo, mas a presença de dispositivos embarcados baseados em Debian deve continuar por vários anos

Implementação e mudanças

• As variáveis time_t estão distribuídas por 6.429 pacotes, o que exigiu um trabalho de grande escala
• Como essa mudança pode quebrar a compatibilidade ABI (Application Binary Interface), os ajustes foram feitos simultaneamente em todas as bibliotecas e pacotes relacionados
• Segundo a equipe de manutenção, esse trabalho foi concluído e testado de forma suficiente

Exceções e planos futuros

• A porta i386 (x86 legado) continuará usando time_t de 32 bits e será mantida com o objetivo de compatibilidade de execução de binários existentes
• A aplicação de tempo em 64 bits e de uma ISA (arquitetura de conjunto de instruções) mais moderna na arquitetura i686 pode ser discutida separadamente
• A porta hurd-i386 não será migrada por falta de suporte no kernel; em vez disso, está em andamento um plano de migração para hurd-amd64

Observações para desenvolvedores

• Desenvolvedores podem testar, pelos métodos orientados na wiki do Debian, se seus softwares não quebram com a adoção de variáveis de tempo em 64 bits
• Mais detalhes e documentação técnica estão disponíveis na wiki do Debian

[GN⁺]

Comentários no Hacker News

• Steve Langasek concentrou-se em resolver esse problema durante os últimos anos de sua vida e liderou grandes avanços; daqui para frente, sempre que eu vir time_t de 64 bits vou lembrar dele
  • Obrigado por trazer essa boa notícia de novo, sinto falta do Steve; fico curioso se Joey ainda continua ativo no Debian
• Sobre o problema do Y2K (o bug do ano 2000 causado pela representação de ano com 2 dígitos), na época economizar 2 bytes tinha muito valor, e como o software dos anos 70 a 90 mudava rapidamente, não se esperava que fosse usado por mais de 5 anos; parece uma visão depreciativa demais
  • Ainda hoje se usa muito ano com 2 dígitos; por exemplo, validade de cartão de crédito (mm/yy) usa essa representação porque é prático escrever curto, e isso basta para a vida útil do cartão, embora em 2100 possa causar problemas de conversão; a maior parte do Y2K veio de problemas de UI (campo de texto com dois caracteres, +1900 hardcoded etc.); o bug de Y2K que vivi diretamente foi um fórum da internet que passou de 1999 para 19100 (erro simples de exibição); Y2K não era um problema só de COBOL
  • Nesses casos, uma “otimização prematura” teria até ajudado; mesmo representando a data como um int simples com zero em 1900, teria economizado ainda mais bytes; com 3 bytes daria para cobrir de 1900 até cerca de 44.000, e com 2 bytes já seria possível cobrir até ~2070
  • O ponto que as pessoas confundem é que não era adicionar 2 bytes, e sim 2 caracteres; em COBOL, tanto números quanto dados eram alocados com largura fixa em quantidade de caracteres, então para colocar um ano com 4 dígitos eram necessárias 4 posições de caractere; esses tamanhos de campo ficavam hardcoded em todo o programa, incluindo acesso a dados, UI, arquivos em lote, arquivos intermediários e arquivos de transmissão
  • Antes do Y2K, eu conhecia gente que comprou muitas opções de venda esperando que as ações de grandes bancos despencassem, mas na prática quase nada aconteceu
  • Trabalhando com COBOL no fim dos anos 80, cheguei a ver um programa que armazenava o ano com apenas 1 dígito; quando ouvi a explicação da estrutura achei estranho, mas os registros eram apagados automaticamente a cada 4 anos, então isso não causava problema no uso e sempre ficava claro de que ano se tratava
• time_t de 64 bits vai resolver a Epochalypse, mas nem todo sistema está simplesmente indo para segundos de 64 bits; o ext4 já mudou para resolução fracionária de 30 bits (nível de nanossegundos) e resolução de segundos de 34 bits, mas mesmo assim o problema deve reaparecer daqui a algumas centenas de anos; imagino que um dia vamos acabar padronizando timestamps de 128 bits com 64 bits para segundos + 64 bits para fração, o que cobriria todo o futuro previsível da história humana
  • Tempo em segundos de 64 bits equivale a cerca de 585 bilhões de anos, segundo cálculo do WolframAlpha
  • Mesmo 64 bits de resolução fracionária talvez não bastem; para chegar perto do tempo de Planck seria preciso usar até 144 bits
  • Fiquei curioso sobre os timestamps do ext4 e também sobre como os sistemas de arquivos zfs e btrfs lidam com tempo; o btrfs provavelmente usa 64 bits, e imagino que o zfs também (posso estar confundindo com o ext4)
• Estão dizendo que o Debian vai resolver o Y2K38, isto é, o problema do Unix Epochalypse, mas na prática a migração para time64_t já foi concluída em todas as portas de 32 bits, exceto i386; o i386 é a exceção por causa da compatibilidade binária legada, e todos os demais, incluindo m68k, já foram alterados; eu mesmo fiz a transição de m68k, powerpc, sh4 e hppa
• time_t não é uma variável, e sim um tipo de dado
  • O conteúdo citado na matéria veio da wiki do Debian; no original está explícito: “time_t realmente aparece em todo lugar. Entre 35.960 pacotes, ele aparece no código-fonte de 6.429. Pacotes que expõem em ABI estruturas contendo time_t precisam fazer a migração de toda a ABI ao mesmo tempo”; a wiki explicava isso com mais clareza do que a matéria
  • “For everything” especifica armel, armhf, hppa, m68k, powerpc e sh4, mas não i386; i386 não tem futuro e o objetivo principal é rodar binários legados/bibliotecas dinâmicas existentes, então não querem quebrá-lo
  • “Previsto para aplicação após o lançamento do Debian 13 Trixie” na verdade significa que isso estará incluído no Trixie
• Seria bom se o limite de tamanho da linha de comando também virasse ilimitado/dinâmico; mesmo com 96 GB de memória, recebo com frequência o erro “argument list too long”, o que é bem incômodo
  • É possível recompilar o kernel para remover o limite do comprimento da linha de comando (cerca de 100 mil caracteres), veja no Stack Overflow, mas isso não parece resolver a questão de fundo; fico me perguntando para que serviria um argumento tão longo quanto um JPEG de 4k
  • Basta aumentar o valor de RLIMIT_STACK; por exemplo, ulimit -s 4000 define uma pilha de 4 MB; para algo maior, é preciso editar /etc/security/limits.conf e fazer login de novo
  • Talvez dê para empacotar em Electron e passar como requisição HTTP POST em JSON
  • Dá para redefinir MAX_ARG_STRLEN e recompilar o kernel; outra opção é usar uma máquina com tamanho de página maior (por exemplo, kernel RHEL Arm com página de 64k), mas é muito mais fácil usar pipes em vez de buffer de comando para passar dados entre processos
  • O limite de caminho de arquivo é o mesmo tipo de problema; alguns sistemas de build (Debian + python + dh-virtualenv etc.) podem gerar caminhos enormes, e seria mais prático simplesmente permitir isso
• Mesmo mudando para 64 bits, um dia ainda vamos bater no limite; fico pensando o que a humanidade estará fazendo em 4 de dezembro do ano 292277026596 às 15:30:07 UTC
  • Provavelmente estaremos comemorando o centenário da adoção completa do IPv6
  • Dentro de 5 bilhões de anos o Sol terá virado uma gigante vermelha e toda a superfície da Terra terá evaporado
  • Até lá, espero que já tenhamos migrado para um sistema de calendário melhor, embora o problema de timestamp continue existindo
  • Basta ir para tempo de 128 bits
  • Talvez dê para aplicar RFC 2550 (Y10K & beyond), publicada em 1º de abril de 1999
• Já se passaram 11 anos desde que o OpenBSD 5.5 aplicou a mesma mudança, notas de lançamento do OpenBSD 5.5
  • Esse foi um caso em que eles venceram todo mundo; nos anos 90, encontrei a API de 32 bits do OS/2 retornando tempo de 64 bits, então escrevi e usei eu mesmo uma biblioteca padrão C++ com time_t de 64 bits
  • É um pouco outro assunto, mas em momentos assim dá vontade de trocar Linux por OpenBSD no servidor
  • O OpenBSD pode se preocupar menos com compatibilidade, e como também tem muito menos usuários, a chance de bugs ou edge cases durante mudanças assim acaba sendo menor
• Quando dizem “o Debian agora está suficientemente concluído e testado, então a transição será feita após o lançamento do Trixie”, isso quer dizer que não entra no Trixie?
  • As notas de lançamento do Trixie dizem que entra sim, notas de lançamento do Trixie
• É a primeira vez que vejo chamarem o Y2K38 de Unix Epochalypse, mas o nome é fofo e talvez pegue
  • Esse nome aparece até na Wikipedia sobre o Year 2038 Problem; ele se espalhou como piada desde 2017
  • Também existe o projeto epochalypse-project.org
  • A expressão “it’s kind of fetch” parece ser uma referência ao filme Mean Girls
  • Faltam cerca de 12 anos, 5 meses, 22 dias, 13 horas e 22 minutos para a Epochalypse