O relógio do Linux falhará em 19 de janeiro de 2038 3:14:08?
23
Estou um pouco preocupado com isso. É chamado de "problema do ano 2038". O kernel Linux ou Ubuntu está pronto para lidar com datas após isso ainda, a partir de 12.04?
Você já tentou ajustar o relógio para algo como 19 de janeiro de 2038 3:14:07 e espera um segundo?
Gtvdijk
2
Vamos supor que esse problema existe e ainda não foi corrigido. A versão 12.04 não será suportada para sempre, portanto você e todas as outras pessoas estarão em uma distribuição atualizada até que isso aconteça, pois há muitos anos. A atualização é fácil. Uma dessas atualizações certamente conterá uma correção. Portanto, não há razão para se preocupar, mas essa é realmente uma pergunta interessante.
verpfeilt
3
O bug já foi corrigido.
ThePiercingPrince
O relógio do sistema não funciona (não em um kernel razoavelmente recente); algumas estruturas de dados (e os programas que a utilizam) podem exibir comportamento anômalo. Na minha opinião, isso será um problema com os dispositivos incorporados - é muito menos provável que eles estejam executando o código atual.
Piskvor
1
@hmayag: Eu não estava pensando em "torradeira", mais como "controlador de semáforo". Essas coisas são um pouco mais robustas que os eletrônicos de consumo e podem facilmente exceder a vida útil (com substituições de peças , mas possivelmente sem atualizações) - IIRC, houve alguns problemas com esses eletrônicos dos anos 80 logo após o Y2K.
Piskvor
Respostas:
13
Não, não irá falhar. Na pior das hipóteses, do ponto de vista de um programador, ele funcionará conforme o esperado: será redefinido para a data 1901-12-13 20:45:52:
Nesse caso, você não atualizará suas distribuições atuais até que isso aconteça. "A atualização é fácil. Uma dessas atualizações certamente conterá uma correção ", disse chocobai .
Lembro que era o mesmo problema / pergunta com máquinas de 16 bits antes de 2000 e, no final, não havia nenhum problema.
Uma solução da Wikipedia:
A maioria dos sistemas operacionais projetados para executar em hardware de 64 bits já usa time_tnúmeros inteiros assinados de 64 bits . O uso de um valor assinado de 64 bits apresenta uma nova data envolvente que é vinte vezes maior que a idade estimada do universo: daqui a aproximadamente 292 bilhões de anos, às 15:30:08 de domingo, 4 de dezembro, 292.277.026.596. A capacidade de fazer cálculos em datas é limitada pelo fato de quetm_yearusa um valor int assinado de 32 bits a partir de 1900 para o ano. Isso limita o ano a um máximo de 2.147.485.547 (2.147.483.647 + 1900). Enquanto isso resolve o problema de execução de programas, não resolve o problema de armazenar valores de data em arquivos de dados binários, muitos dos quais empregam formatos rígidos de armazenamento. Também não resolve o problema de programas de 32 bits em execução em camadas de compatibilidade e pode não resolver o problema de programas que armazenam incorretamente valores de tempo em variáveis de tipos diferentes de time_t.
Uso o Ubuntu 13.04 em 64 bits e, por curiosidade, mudei manualmente o horário para 2038-01-19 03:13:00. Após 03:14:08 nada aconteceu:
Portanto, não há nada para se preocupar com esse problema.
Se for redefinido, falhará porque "falhar" significa "não funcionar ou trabalhar incorretamente".
ThePiercingPrince
1
@LinuxDistance Isso acontece do seu ponto de vista. Mas do ponto de vista de um programador, ele funcionará conforme o esperado: será redefinido . O mesmo aconteceu com o fim do calendário maia: o mundo não falhou por causa disso.
Radu Rădeanu
10
Discordo? do ponto de vista de um programador um relógio não é suposto reset, por isso vai falhar
Nanne
3
Essa discussão nos comentários é inútil. A pergunta é "O kernel do Linux ou Ubuntu está pronto para lidar com datas após isso?". Bem, ele não é capaz de lidar com essas datas, portanto falha no contexto desta questão.
Gtvdijk
2
@gertvdijk "O kernel Linux " atual / real "ou o Ubuntu está pronto para lidar com datas após isso?"
Radu Rădeanu 28/05
7
Você pode verificar se o tempo do seu computador falhará usando o seguinte script Perl:
#!/usr/bin/perl
use POSIX;
$ENV{'TZ'} = "GMT";
for ($clock = 2147483641; $clock < 2147483651; $clock++) {
print ctime($clock);
}
Se o seu computador estiver bom, você receberá o seguinte:
Tue Jan 19 03:14:01 2038
Tue Jan 19 03:14:02 2038
Tue Jan 19 03:14:03 2038
Tue Jan 19 03:14:04 2038
Tue Jan 19 03:14:05 2038
Tue Jan 19 03:14:06 2038
Tue Jan 19 03:14:07 2038 <-- Last second in 32-bit Unix systems
Tue Jan 19 03:14:08 2038
Tue Jan 19 03:14:09 2038
Tue Jan 19 03:14:10 2038
Se o seu computador for como o meu, ele será dividido desta maneira:
Tue Jan 19 03:14:01 2038
Tue Jan 19 03:14:02 2038
Tue Jan 19 03:14:03 2038
Tue Jan 19 03:14:04 2038
Tue Jan 19 03:14:05 2038
Tue Jan 19 03:14:06 2038
Tue Jan 19 03:14:07 2038
Fri Dec 13 20:45:52 1901
Fri Dec 13 20:45:52 1901
Fri Dec 13 20:45:52 1901
Também poderia fazer isso:
Tue Jan 19 03:14:01 2038
Tue Jan 19 03:14:02 2038
Tue Jan 19 03:14:03 2038
Tue Jan 19 03:14:04 2038
Tue Jan 19 03:14:05 2038
Tue Jan 19 03:14:06 2038
Tue Jan 19 03:14:07 2038
Tue Jan 19 03:14:07 2038
Tue Jan 19 03:14:07 2038
Tue Jan 19 03:14:07 2038
Acho que você está testando Perl aqui e não o sistema operacional real no núcleo. Ou você, com o uso de ctime?
gertvdijk
@gertvdijk Bem, ele fornece a primeira saída em computadores corrigidos, e meu laptop Ubuntu fornece a segunda, enquanto a terceira é do meu servidor Debian. Na verdade, eu não escrevi o código, está em toda a Internet da mesma forma exata.
SkylarMT
2
confirmado. se você tiver uma máquina de 64 bits, tudo ficará bem. Além disso ... quem de nós terá apenas máquinas de 32 bits ainda em execução no ano de 2038?
Jrg
1
Procurei isso para ilustrar o problema de 2038 a um colega de trabalho e, 2 anos depois de fazer o comentário acima, tenho muito pouca dúvida de que em 2038 teremos máquinas de 32 bits que falharão. Ah, otimismo juvenil.
Jrg 5/08
@ James, talvez alguns sem querer. Provavelmente haverá Linux embarcado de 32 bits nos dispositivos IoT, sem remendo. Fim do mundo? Não. Algum problema em alguns lugares? Definitivamente.
Prof. Falken suporta Monica
3
Escrevi e publiquei um pequeno artigo sobre isso em 1996. Isso incluía um pequeno programa em C para demonstrá-lo. Também tive e-mails com David Mills sobre problemas semelhantes com o NTP, o Network Time Protocol. No meu laptop Ubuntu 14.04 de 64 bits, o código perl não exibia a limitação, portanto as bibliotecas de 64 bits subjacentes devem ter sido modificadas.
No entanto, a execução do meu código de teste há muito tempo mostra o tempo que remonta à época do UNIX. Portanto, nem tudo está bem com o código de 32 bits do passado.
Meu artigo de 1996, O tempo UNIX se esgotará em 2038! está no meu site desde cerca de 2000. Uma variante deste título "UNIX Time" foi publicada em 1998 no "Ano 2000 Melhores Práticas para a Computação do Milênio Y2K" ISBN 0136465064.
O Linux de 64 bits está pronto, pelo menos se você estiver falando sobre as principais interfaces do sistema operacional (aplicativos individuais, é claro, ainda podem estragar tudo). O time_t é tradicionalmente definido como um alias para "long" e "long" no Linux de 64 bits.
A situação do Linux de 32 bits (e a camada de compatibilidade dos binários de 32 bits no Linux de 64 bits) é muito menos otimista. Está quebrado e corrigi-lo sem quebrar todos os binários existentes não é uma tarefa fácil. Um monte de APIs usa time_t e, em muitos casos, é incorporado como parte das estruturas de dados, para que as APIs não sejam apenas duplicadas, mas também as estruturas de dados com as quais trabalham.
Mesmo se houver algum nível de compatibilidade com versões anteriores, todos os binários que desejam obter o tempo correto precisarão ser reconstruídos para usar as novas interfaces de tempo de 64 bits.
Respostas:
Não, não irá falhar. Na pior das hipóteses, do ponto de vista de um programador, ele funcionará conforme o esperado: será redefinido para a data 1901-12-13 20:45:52:
Nesse caso, você não atualizará suas distribuições atuais até que isso aconteça. "A atualização é fácil. Uma dessas atualizações certamente conterá uma correção ", disse chocobai .
Lembro que era o mesmo problema / pergunta com máquinas de 16 bits antes de 2000 e, no final, não havia nenhum problema.
Uma solução da Wikipedia:
Uso o Ubuntu 13.04 em 64 bits e, por curiosidade, mudei manualmente o horário para 2038-01-19 03:13:00. Após 03:14:08 nada aconteceu:
Portanto, não há nada para se preocupar com esse problema.
Mais sobre:
fonte
Você pode verificar se o tempo do seu computador falhará usando o seguinte script Perl:
Se o seu computador estiver bom, você receberá o seguinte:
Se o seu computador for como o meu, ele será dividido desta maneira:
Também poderia fazer isso:
fonte
ctime?Escrevi e publiquei um pequeno artigo sobre isso em 1996. Isso incluía um pequeno programa em C para demonstrá-lo. Também tive e-mails com David Mills sobre problemas semelhantes com o NTP, o Network Time Protocol. No meu laptop Ubuntu 14.04 de 64 bits, o código perl não exibia a limitação, portanto as bibliotecas de 64 bits subjacentes devem ter sido modificadas.
No entanto, a execução do meu código de teste há muito tempo mostra o tempo que remonta à época do UNIX. Portanto, nem tudo está bem com o código de 32 bits do passado.
Meu artigo de 1996, O tempo UNIX se esgotará em 2038! está no meu site desde cerca de 2000. Uma variante deste título "UNIX Time" foi publicada em 1998 no "Ano 2000 Melhores Práticas para a Computação do Milênio Y2K" ISBN 0136465064.
fonte
O Linux de 64 bits está pronto, pelo menos se você estiver falando sobre as principais interfaces do sistema operacional (aplicativos individuais, é claro, ainda podem estragar tudo). O time_t é tradicionalmente definido como um alias para "long" e "long" no Linux de 64 bits.
A situação do Linux de 32 bits (e a camada de compatibilidade dos binários de 32 bits no Linux de 64 bits) é muito menos otimista. Está quebrado e corrigi-lo sem quebrar todos os binários existentes não é uma tarefa fácil. Um monte de APIs usa time_t e, em muitos casos, é incorporado como parte das estruturas de dados, para que as APIs não sejam apenas duplicadas, mas também as estruturas de dados com as quais trabalham.
Mesmo se houver algum nível de compatibilidade com versões anteriores, todos os binários que desejam obter o tempo correto precisarão ser reconstruídos para usar as novas interfaces de tempo de 64 bits.
Houve algum trabalho realizado (veja, por exemplo, https://lwn.net/Articles/643234/ e http://www.sourceware.org/ml/libc-alpha/2015-10/msg00893.html ), mas afirmamos que ainda estão muito longe de uma solução completa. Não está claro se haverá ou não distribuições de 32 bits de uso geral que são seguras para o Y2K38.
fonte