O ano de 2038 problema ou bug do ano de 2038 (no Canadá), também conhecido como Y2038 , é um bug de computador semelhante ao de 2000 bug do ano que poderiam perturbar o funcionamento de muitos sistemas de TI a19 de janeiro de 2038às 3 h 14 min 8 s , tempo universal . Eles então exibirão13 de dezembro de 1901e 20 h 45 min 52 s .
Este bug afeta potencialmente todos os sistemas operacionais e programas que usam uma representação de data de 32 bits . Afeta formatos de arquivo (como ZIP ), sistemas de arquivos (como o sistema de arquivos FAT usado na maioria das unidades USB e cartões flash) e sistemas operacionais em todos os níveis (do kernel ao sistema e operação em linguagens de programação ), ou mesmo o relógio de tempo real em si.
O problema é com o software que usa a representação POSIX do tempo , em que o tempo é representado como um número de segundos decorridos desde o1 ° de janeiro de 1970à meia-noite ( 0 horas ), hora universal . Em computadores de 32 bits, a maioria dos afetados sistemas operacionais representar este número como um de 32 bits assinado inteiro, o que limita o número de segundos para 231 - 1, quando ou 2147483 647 segundos (01111111 11111111 11111111 11111111 em binário ). Este número máximo será alcançado em19 de janeiro de 2038às 3 h 14 min 7 s (tempo universal). No próximo segundo, a representação de tempo "fará um loop" (10000000 00000000 00000000 00000000 em binário) e representará -2147 483 648 em complemento de dois , e assim o computador exibirá a data do13 de dezembro de 1901.
O software afetado é muito numeroso, porque o padrão POSIX , inspirado nos sistemas UNIX , tem sido usado para muitos programas escritos em linguagem C para muitos sistemas operacionais. Para aqueles do tipo Unix que representam o tempo por um inteiro de 32 bits sem sinal (em conformidade com o padrão POSIX), o prazo final é em 2106 e não em 2038. Esses sistemas operacionais são, no entanto, minoria. Mudar para um carimbo de data / hora de 64 bits introduziria um novo prazo final no domingo4 de dezembro de 292277026596ap. BC em 15 h 30 min 8 s (aproximadamente 21 vezes a idade do universo ) e assim resolver o problema, porque os 64 bits permitiriam ao computador empurrar o limite para 2 63 - 1 segundos.
No domínio do aplicativo, o problema foi revelado já na década de 2010, já que o do ano 2000 foi revelado já na década de 1980 sobre os cronogramas dos planos de longo prazo ( desde então, as planilhas têm usado datas variáveis ou formato longo) .
Não há uma solução única para esse problema, pois os carimbos de data / hora de 32 bits também estão presentes em vários formatos de arquivo atuais (por exemplo, formato ZIP ). Uma mudança de representação em computadores tornaria inoperantes os programas que exploram a equivalência atual entre a representação interna e o formato do arquivo. Portanto, muito trabalho será necessário "nos bastidores" para que quase nada apareça na superfície, o que já acontecia ao se aproximar o ano 2000.
Muitas estruturas de dados que estão em uso hoje têm representações de tempo no formato de 32 bits , em particular, para as mais conhecidas:
Exemplos de sistemas que usam formatos de tempo de 32 bits:
Os sistemas operacionais que usam o kernel Linux de 64 bits são todos imunes.
A versão 3.17 do kernel Linux usa uma representação interna de datas em 64 bits, que prepara as outras adaptações necessárias, ao nível das bibliotecas C padrão e depois das aplicações.
AndroidO Marshmallow versão 6.0 do Android baseado no kernel Linux 3.10 não incorpora nenhuma correção.
janelasNo Visual C 8, o tempo é codificado em 64 bits por padrão.
No Visual C 7.1, o desenvolvedor deve usar explicitamente o tempo de 64 bits.
As datas agora são consideradas não assinadas, estendendo sua vida útil em 68 anos.
Os seguintes sistemas codificam suas datas em 64 bits:
Network Time Protocol (NTP) usa uma data base no1 ° de janeiro de 1900codificado em 64 bits, dos quais 32 bits representam os segundos. Portanto, não está sujeito ao bug do ano 2038, mas sim ao bug do ano 2036.
O NTPv4 usa os campos “número da era” e “início da era” que irão contornar o bug.
As seguintes versões do protocolo usarão datas codificadas em 128 bits, dos quais 64 bits representarão os segundos.
Não existe uma solução única para todos os problemas que surgirão como resultado do bug do ano 2038. Qualquer alteração na definição do tipo de variável usada para denotar o tempo time_tcausaria problemas de compatibilidade de código em todos eles. aplicativos em que a representação de data e hora depende de um sistema projetado para funcionar com um número inteiro assinado de 32 bits. Por exemplo, mudar time_tpara um número inteiro de 32 bits sem sinal, o que permitiria que os sistemas fossem usados até o ano 2106, causaria complicações para programas que manipulam dados que têm datas anteriores ao ano. Ano 1970 porque tais datas seriam representadas por inteiros negativos. Além disso, expandir a variável time_tpara um número inteiro de 64 bits em sistemas em uso atual produziria mudanças incompatíveis na organização das estruturas e na interface binária de certas funções.
A solução mais simples proposta é mudar o sistema, passando de 32 bits para 64 bits . De fato, atualmente, a maioria dos sistemas de computador projetados para usar hardware de 64 bits já opera com variáveis de time_t64 bits.